You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by David Jencks <da...@coredevelopers.net> on 2003/12/26 20:01:01 UTC
Is ejb spec ambiguous about transaction attributes?
I don't see anything in the ejb 2.1 spec that indicates how to
interpret transaction attributes such as these:
<container-transaction>
<method>
<ejb-name>MyEJB</ejb-name>
<method-intf>Local<method-intf>
<method-name>*</method-name>
</method>
<trans-attribute>Required</trans-attribute>
</container-transaction>
<container-transaction>
<method>
<ejb-name>MyEJB</ejb-name>
<method-intf>Remote<method-intf>
<method-name>*</method-name>
</method>
<trans-attribute>Supported</trans-attribute>
</container-transaction>
<container-transaction>
<method>
<ejb-name>MyEJB</ejb-name>
<!-- doSomething is in both local and remote interfaces -->
<method-name>doSomething</method-name>
</method>
<trans-attribute>RequiresNew</trans-attribute>
</container-transaction>
I assume that the third overrides the other two, but I don't see that
specified anywhere. Any help?
thanks
david jencks
Re: Is ejb spec ambiguous about transaction attributes?
Posted by David Jencks <da...@coredevelopers.net>.
Ok, thanks.
I'd be a lot more comfortable if they explicitly mentioned that type n
overrides type n-1 whether or not either one has an explicit
method-intf.
david
On Friday, December 26, 2003, at 02:09 PM, Jeremy Boynes wrote:
> David Jencks wrote:
>> I don't see anything in the ejb 2.1 spec that indicates how to
>> interpret transaction attributes such as these:
>> <container-transaction>
>> <method>
>> <ejb-name>MyEJB</ejb-name>
>> <method-intf>Local<method-intf>
>> <method-name>*</method-name>
>> </method>
>> <trans-attribute>Required</trans-attribute>
>> </container-transaction>
>> <container-transaction>
>> <method>
>> <ejb-name>MyEJB</ejb-name>
>> <method-intf>Remote<method-intf>
>> <method-name>*</method-name>
>> </method>
>> <trans-attribute>Supported</trans-attribute>
>> </container-transaction>
>> <container-transaction>
>> <method>
>> <ejb-name>MyEJB</ejb-name>
>> <!-- doSomething is in both local and remote interfaces -->
>> <method-name>doSomething</method-name>
>> </method>
>> <trans-attribute>RequiresNew</trans-attribute>
>> </container-transaction>
>> I assume that the third overrides the other two, but I don't see that
>> specified anywhere. Any help?
>> thanks
>> david jencks
>
> [EJB2.1 pp 378] "If there is also a container-transaction element that
> uses Style 1 element for the same bean, the value specified by the
> Style 2 element takes precedence." And similarly for Style 3.
>
> So your 3rd case, which is Style 2, overrides the first two which are
> both Style 1.
>
> Or so I read it :-)
>
> --
> Jeremy
>
Re: Is ejb spec ambiguous about transaction attributes?
Posted by Jeremy Boynes <je...@coredevelopers.net>.
David Jencks wrote:
> I don't see anything in the ejb 2.1 spec that indicates how to interpret
> transaction attributes such as these:
>
> <container-transaction>
> <method>
> <ejb-name>MyEJB</ejb-name>
> <method-intf>Local<method-intf>
> <method-name>*</method-name>
> </method>
> <trans-attribute>Required</trans-attribute>
> </container-transaction>
>
> <container-transaction>
> <method>
> <ejb-name>MyEJB</ejb-name>
> <method-intf>Remote<method-intf>
> <method-name>*</method-name>
> </method>
> <trans-attribute>Supported</trans-attribute>
> </container-transaction>
>
> <container-transaction>
> <method>
> <ejb-name>MyEJB</ejb-name>
> <!-- doSomething is in both local and remote interfaces -->
> <method-name>doSomething</method-name>
> </method>
> <trans-attribute>RequiresNew</trans-attribute>
> </container-transaction>
>
> I assume that the third overrides the other two, but I don't see that
> specified anywhere. Any help?
>
> thanks
> david jencks
>
[EJB2.1 pp 378] "If there is also a container-transaction element that
uses Style 1 element for the same bean, the value specified by the Style
2 element takes precedence." And similarly for Style 3.
So your 3rd case, which is Style 2, overrides the first two which are
both Style 1.
Or so I read it :-)
--
Jeremy