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 Blevins <da...@visi.com> on 2007/08/01 08:53:55 UTC
Re: Problems with method level container transactions in Geronimo 2.0 / OpenEJB
On Jul 25, 2007, at 7:57 PM, Christopher Blythe wrote:
> I was working on DayTrader 2.0 when I found that the resetTrade
> method for all of the runtime modes (with the exception of Direct
> mode) would fail. I went back and deploy DayTrader 1.2 on GMO 2.0
> and noticed the same behavior. I then went back and deploy DT 1.2
> on GMO 1.1.1 and resetTrade worked for EJB mode like a champ.
>
> If you look in the ejb-jar.xml and check out the container
> transactions, you see the following...
>
> <container-transaction>
> <method>
> <ejb-name>TradeEJB</ejb-name>
> <method-intf>Remote</method-intf>
> <method-name>resetTrade</method-name>
> <method-params>
> <method-param>boolean</method-param>
> </method-params>
> </method>
> ...
> <trans-attribute>NotSupported</trans-attribute>
> </container-transaction>
>
> <container-transaction>
> ...
> <method>
> <ejb-name>TradeEJB</ejb-name>
> <method-name>*</method-name>
> </method>
> ...
> <trans-attribute>Required</trans-attribute>
> </container-transaction>
Took me a couple hours to dig through this but basically what is
happening is that the second transaction attribute declaration for
TradeEJB (method "*") is essentially overwriting the first (method
"resetTrade(boolean)). These are processed in the order they are
declared so fixing it should be as easy as moving the "resetTrade
(boolean)" declaration to be after the "*" declaration.
If you know of a part of the EJB spec that is relevant I'm definitely
all ears -- as far as I know it's valid to process them in the order
they are declared.
For the future (not 2.0) and provided it isn't explicitly prohibited
by the spec, we could possibly order the container-transaction
declarations for an ejb from least specific to most specific and
process them that way -- like we do for interceptor-bindings. If you
had some time to do some leg work on digging through the spec that'd
be great.
-David
> The impl for resetTrade in the TradeEJB session bean calls to the
> TradeDirect code in order to perform the reset. The TradeDirect
> code manages the transaction commits on its own. That is why the
> resetTrade method in TradeEJB was marked as NotSupported.
>
> As I mentioned earlier, this was recognized by the Geronimo 1.1.1
> container; however, it looks like the Geronimo 2.0 container is not
> picking this up.
>
> A look at some of the OpenEJB trace information seems to confirm
> this...
>
> 22:11:51,437 INFO [OpenEJB] invoking method resetTrade on ejb/
> TradeEJB with identity null
> 22:11:51,437 INFO [Transaction] TX Required: Started transaction
> org.apache.geronimo.transaction.manager.TransactionImpl@240a240a
> 22:11:51,437 TRACE [SinglePoolConnectionInterceptor] Supplying
> pooled connection MCI:
> org.apache.geronimo.connector.outbound.ManagedConnectionInfo@183e183e
> MC: org.tranql.connector.jdbc.ManagedXAConnection@29fa29fa from
> pool:
> org.apache.geronimo.connector.outbound.SinglePoolConnectionInterceptor
> @56525652
> 22:11:51,437 TRACE [TransactionCachingInterceptor] supplying
> connection from pool null for managed connection
> org.tranql.connector.jdbc.ManagedXAConnection@29fa29fa to tx
> caching interceptor
> org.apache.geronimo.connector.outbound.TransactionCachingInterceptor@5
> c005c00
> 22:11:51,546 ERROR [Log] Error: Failed to reset Trade
>
> Just for reference, here is the exception that is being thrown....
>
> 22:51:04,031 ERROR [Log] Error: Failed to reset Trade
>
> com.ibm.db2.jcc.b.SqlException: setAutoCommit(true) invalid
> during global transaction
> com.ibm.db2.jcc.b.SqlException: setAutoCommit(true) invalid during
> global transaction
> at com.ibm.db2.jcc.b.p.setAutoCommit(p.java:1152)
> at com.ibm.db2.jcc.b.dc.setAutoCommit(dc.java:151)
> at
> org.tranql.connector.jdbc.ManagedXAConnection.localTransactionCommit
> (ManagedXAConnection.java :104)
> at org.tranql.connector.AbstractManagedConnection
> $LocalTransactionImpl.commit(AbstractManagedConnection.java:192)
> at org.tranql.connector.jdbc.ConnectionHandle.commit
> (ConnectionHandle.java:115)
> at
> org.apache.geronimo.samples.daytrader.direct.TradeDirect.commit
> (TradeDirect.java:2044)
> at
> org.apache.geronimo.samples.daytrader.direct.TradeDirect.resetTrade
> (TradeDirect.java:1964)
> at
> org.apache.geronimo.samples.daytrader.ejb.TradeBean.resetTrade
> (TradeBean.java:931)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java :64)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:615)
> at
> org.apache.openejb.core.interceptor.ReflectionInvocationContext
> $Invocation.invoke (ReflectionInvocationContext.java:146)
> at
> org.apache.openejb.core.interceptor.ReflectionInvocationContext.procee
> d(ReflectionInvocationContext.java:129)
> at
> org.apache.openejb.core.interceptor.InterceptorStack.invoke
> (InterceptorStack.java:67)
> at
> org.apache.openejb.core.stateless.StatelessContainer._invoke
> (StatelessContainer.java:203)
> at
> org.apache.openejb.core.stateless.StatelessContainer.invoke
> (StatelessContainer.java :165)
> ...
>
> Anyone have any thoughts on this one?
>
> Chris
>
> --
> "I say never be complete, I say stop being perfect, I say let...
> lets evolve, let the chips fall where they may." - Tyler Durden
Re: Problems with method level container transactions in Geronimo 2.0 / OpenEJB
Posted by David Blevins <da...@visi.com>.
On Aug 1, 2007, at 12:17 PM, David Blevins wrote:
> That's the info I was looking for. I'll fix this.
Should be good now.
-David
>
> -David
>
> On Aug 1, 2007, at 9:03 AM, David Jencks wrote:
>
>> And section 13.3.7.2.1 very clearly states in great detail that
>> more specific xml overrides less specific xml. So IMO there's a
>> bug in openejb's current behavior.
>>
>> thanks
>> david jencks
>> On Aug 1, 2007, at 9:00 AM, David Jencks wrote:
>>
>>> The spec is clear about this case anyway, on p 336 it says
>>>
>>> Atransactionattributemaybespecifiedonamethodof thebeanclass
>>> tooverridethetransaction
>>> attribute value explicitly or implicitly specified on the bean
>>> class.
>>>
>>>
>>> thanks
>>> david jencks
>>>
>>> On Aug 1, 2007, at 5:17 AM, Christopher Blythe wrote:
>>>
>>>> David...
>>>>
>>>> Any idea how this will be handled in EJB 3 beans when the
>>>> transaction attributes are defined in the annotations? If I were
>>>> to define a transaction annotation for the whole bean and
>>>> another for an individual method, would the method level
>>>> attribute be ignored?
>>>>
>>>> Chris
>>>>
>>>> On 8/1/07, David Blevins <da...@visi.com> wrote: On Jul
>>>> 25, 2007, at 7:57 PM, Christopher Blythe wrote:
>>>>
>>>> > I was working on DayTrader 2.0 when I found that the resetTrade
>>>> > method for all of the runtime modes (with the exception of Direct
>>>> > mode) would fail. I went back and deploy DayTrader 1.2 on GMO 2.0
>>>> > and noticed the same behavior. I then went back and deploy DT 1.2
>>>> > on GMO 1.1.1 and resetTrade worked for EJB mode like a champ.
>>>> >
>>>> > If you look in the ejb-jar.xml and check out the container
>>>> > transactions, you see the following...
>>>> >
>>>> > <container-transaction>
>>>> > <method>
>>>> > <ejb-name>TradeEJB</ejb-name>
>>>> > <method-intf>Remote</method-intf>
>>>> > <method-name>resetTrade</method-name>
>>>> > <method-params>
>>>> > <method-param>boolean</method-param>
>>>> > </method-params>
>>>> > </method>
>>>> > ...
>>>> > <trans-attribute>NotSupported</trans-attribute>
>>>> > </container-transaction>
>>>> >
>>>> > <container-transaction>
>>>> > ...
>>>> > <method>
>>>> > <ejb-name>TradeEJB</ejb-name>
>>>> > <method-name>*</method-name>
>>>> > </method>
>>>> > ...
>>>> > <trans-attribute>Required</trans-attribute>
>>>> > </container-transaction>
>>>>
>>>> Took me a couple hours to dig through this but basically what is
>>>> happening is that the second transaction attribute declaration for
>>>> TradeEJB (method "*") is essentially overwriting the first (method
>>>> "resetTrade(boolean)). These are processed in the order they are
>>>> declared so fixing it should be as easy as moving the "resetTrade
>>>> (boolean)" declaration to be after the "*" declaration.
>>>>
>>>> If you know of a part of the EJB spec that is relevant I'm
>>>> definitely
>>>> all ears -- as far as I know it's valid to process them in the
>>>> order
>>>> they are declared.
>>>>
>>>> For the future (not 2.0) and provided it isn't explicitly
>>>> prohibited
>>>> by the spec, we could possibly order the container-transaction
>>>> declarations for an ejb from least specific to most specific and
>>>> process them that way -- like we do for interceptor-bindings.
>>>> If you
>>>> had some time to do some leg work on digging through the spec
>>>> that'd
>>>> be great.
>>>>
>>>> -David
>>>>
>>>>
>>>> > The impl for resetTrade in the TradeEJB session bean calls to the
>>>> > TradeDirect code in order to perform the reset. The TradeDirect
>>>> > code manages the transaction commits on its own. That is why the
>>>> > resetTrade method in TradeEJB was marked as NotSupported.
>>>> >
>>>> > As I mentioned earlier, this was recognized by the Geronimo 1.1.1
>>>> > container; however, it looks like the Geronimo 2.0 container
>>>> is not
>>>> > picking this up.
>>>> >
>>>> > A look at some of the OpenEJB trace information seems to confirm
>>>> > this...
>>>> >
>>>> > 22:11:51,437 INFO [OpenEJB] invoking method resetTrade on ejb/
>>>> > TradeEJB with identity null
>>>> > 22:11:51,437 INFO [Transaction] TX Required: Started transaction
>>>> > org.apache.geronimo.transaction.manager.TransactionImpl@240a240a
>>>> > 22:11:51,437 TRACE [SinglePoolConnectionInterceptor] Supplying
>>>> > pooled connection MCI:
>>>> >
>>>> org.apache.geronimo.connector.outbound.ManagedConnectionInfo@183e18
>>>> 3e
>>>> > MC: org.tranql.connector.jdbc.ManagedXAConnection@29fa29fa from
>>>> > pool:
>>>> >
>>>> org.apache.geronimo.connector.outbound.SinglePoolConnectionIntercep
>>>> tor
>>>> > @56525652
>>>> > 22:11:51,437 TRACE [TransactionCachingInterceptor] supplying
>>>> > connection from pool null for managed connection
>>>> > org.tranql.connector.jdbc.ManagedXAConnection@29fa29fa to tx
>>>> > caching interceptor
>>>> >
>>>> org.apache.geronimo.connector.outbound.TransactionCachingIntercepto
>>>> r@5
>>>> > c005c00
>>>> > 22:11:51,546 ERROR [Log] Error: Failed to reset Trade
>>>> >
>>>> > Just for reference, here is the exception that is being
>>>> thrown....
>>>> >
>>>> > 22:51:04,031 ERROR [Log] Error: Failed to reset Trade
>>>> >
>>>> > com.ibm.db2.jcc.b.SqlException: setAutoCommit(true)
>>>> invalid
>>>> > during global transaction
>>>> > com.ibm.db2.jcc.b.SqlException : setAutoCommit(true) invalid
>>>> during
>>>> > global transaction
>>>> > at com.ibm.db2.jcc.b.p.setAutoCommit(p.java:1152)
>>>> > at com.ibm.db2.jcc.b.dc.setAutoCommit(dc.java:151)
>>>> > at
>>>> >
>>>> org.tranql.connector.jdbc.ManagedXAConnection.localTransactionCommi
>>>> t
>>>> > (ManagedXAConnection.java :104)
>>>> > at org.tranql.connector.AbstractManagedConnection
>>>> > $LocalTransactionImpl.commit(AbstractManagedConnection.java :192)
>>>> > at org.tranql.connector.jdbc.ConnectionHandle.commit
>>>> > (ConnectionHandle.java:115)
>>>> > at
>>>> > org.apache.geronimo.samples.daytrader.direct.TradeDirect.commit
>>>> > (TradeDirect.java :2044)
>>>> > at
>>>> >
>>>> org.apache.geronimo.samples.daytrader.direct.TradeDirect.resetTrade
>>>> > (TradeDirect.java:1964)
>>>> > at
>>>> > org.apache.geronimo.samples.daytrader.ejb.TradeBean.resetTrade
>>>> > (TradeBean.java:931)
>>>> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
>>>> Method)
>>>> > at sun.reflect.NativeMethodAccessorImpl.invoke
>>>> > (NativeMethodAccessorImpl.java :64)
>>>> > at sun.reflect.DelegatingMethodAccessorImpl.invoke
>>>> > (DelegatingMethodAccessorImpl.java:43)
>>>> > at java.lang.reflect.Method.invoke(Method.java:615)
>>>> > at
>>>> > org.apache.openejb.core.interceptor.ReflectionInvocationContext
>>>> > $Invocation.invoke (ReflectionInvocationContext.java:146)
>>>> > at
>>>> >
>>>> org.apache.openejb.core.interceptor.ReflectionInvocationContext.pro
>>>> cee
>>>> > d(ReflectionInvocationContext.java:129)
>>>> > at
>>>> > org.apache.openejb.core.interceptor.InterceptorStack.invoke
>>>> > (InterceptorStack.java:67)
>>>> > at
>>>> > org.apache.openejb.core.stateless.StatelessContainer._invoke
>>>> > (StatelessContainer.java :203)
>>>> > at
>>>> > org.apache.openejb.core.stateless.StatelessContainer.invoke
>>>> > (StatelessContainer.java :165)
>>>> > ...
>>>> >
>>>> > Anyone have any thoughts on this one?
>>>> >
>>>> > Chris
>>>> >
>>>> > --
>>>> > "I say never be complete, I say stop being perfect, I say let...
>>>> > lets evolve, let the chips fall where they may." - Tyler Durden
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> "I say never be complete, I say stop being perfect, I say let...
>>>> lets evolve, let the chips fall where they may." - Tyler Durden
>>>
>>
>>
>
>
Re: Problems with method level container transactions in Geronimo 2.0 / OpenEJB
Posted by David Blevins <da...@visi.com>.
On Aug 1, 2007, at 2:44 PM, David Blevins wrote:
>
> On Aug 1, 2007, at 1:49 PM, Christopher Blythe wrote:
>
>> David...
>>
>> Do you have a JIRA for this yet?
>
>
> Added one here http://issues.apache.org/jira/browse/OPENEJB-623
Here click the this link to be notified of when it's fixed:
http://issues.apache.org/jira/secure/ViewIssue.jspa?
id=12375174&watch=true
-David
>
> -David
>
>>
>>
>>
>> On 8/1/07, David Blevins <david.blevins@visi.com > wrote:That's
>> the info I was looking for. I'll fix this.
>>
>> -David
>>
>> On Aug 1, 2007, at 9:03 AM, David Jencks wrote:
>>
>> > And section 13.3.7.2.1 very clearly states in great detail that
>> > more specific xml overrides less specific xml. So IMO there's a
>> > bug in openejb's current behavior.
>> >
>> > thanks
>> > david jencks
>> > On Aug 1, 2007, at 9:00 AM, David Jencks wrote:
>> >
>> >> The spec is clear about this case anyway, on p 336 it says
>> >>
>> >> Atransactionattributemaybespecifiedonamethodof thebeanclass
>> >> tooverridethetransaction
>> >> attribute value explicitly or implicitly specified on the bean
>> class.
>> >>
>> >>
>> >> thanks
>> >> david jencks
>> >>
>> >> On Aug 1, 2007, at 5:17 AM, Christopher Blythe wrote:
>> >>
>> >>> David...
>> >>>
>> >>> Any idea how this will be handled in EJB 3 beans when the
>> >>> transaction attributes are defined in the annotations? If I were
>> >>> to define a transaction annotation for the whole bean and another
>> >>> for an individual method, would the method level attribute be
>> >>> ignored?
>> >>>
>> >>> Chris
>> >>>
>> >>> On 8/1/07, David Blevins < david.blevins@visi.com> wrote: On Jul
>> >>> 25, 2007, at 7:57 PM, Christopher Blythe wrote:
>> >>>
>> >>> > I was working on DayTrader 2.0 when I found that the resetTrade
>> >>> > method for all of the runtime modes (with the exception of
>> Direct
>> >>> > mode) would fail. I went back and deploy DayTrader 1.2 on
>> GMO 2.0
>> >>> > and noticed the same behavior. I then went back and deploy
>> DT 1.2
>> >>> > on GMO 1.1.1 and resetTrade worked for EJB mode like a champ.
>> >>> >
>> >>> > If you look in the ejb-jar.xml and check out the container
>> >>> > transactions, you see the following...
>> >>> >
>> >>> > <container-transaction>
>> >>> > <method>
>> >>> > <ejb-name>TradeEJB</ejb-name>
>> >>> > <method-intf>Remote</method-intf>
>> >>> > <method-name>resetTrade</method-name>
>> >>> > <method-params>
>> >>> > <method-param>boolean</method-param>
>> >>> > </method-params>
>> >>> > </method>
>> >>> > ...
>> >>> > <trans-attribute>NotSupported</trans-attribute>
>> >>> > </container-transaction>
>> >>> >
>> >>> > <container-transaction>
>> >>> > ...
>> >>> > <method>
>> >>> > <ejb-name>TradeEJB</ejb-name>
>> >>> > <method-name>*</method-name>
>> >>> > </method>
>> >>> > ...
>> >>> > <trans-attribute>Required</trans-attribute>
>> >>> > </container-transaction>
>> >>>
>> >>> Took me a couple hours to dig through this but basically what is
>> >>> happening is that the second transaction attribute declaration
>> for
>> >>> TradeEJB (method "*") is essentially overwriting the first
>> (method
>> >>> "resetTrade(boolean)). These are processed in the order they are
>> >>> declared so fixing it should be as easy as moving the "resetTrade
>> >>> (boolean)" declaration to be after the "*" declaration.
>> >>>
>> >>> If you know of a part of the EJB spec that is relevant I'm
>> >>> definitely
>> >>> all ears -- as far as I know it's valid to process them in the
>> order
>> >>> they are declared.
>> >>>
>> >>> For the future (not 2.0) and provided it isn't explicitly
>> prohibited
>> >>> by the spec, we could possibly order the container-transaction
>> >>> declarations for an ejb from least specific to most specific and
>> >>> process them that way -- like we do for interceptor-bindings. If
>> >>> you
>> >>> had some time to do some leg work on digging through the spec
>> that'd
>> >>> be great.
>> >>>
>> >>> -David
>> >>>
>> >>>
>> >>> > The impl for resetTrade in the TradeEJB session bean calls
>> to the
>> >>> > TradeDirect code in order to perform the reset. The TradeDirect
>> >>> > code manages the transaction commits on its own. That is why
>> the
>> >>> > resetTrade method in TradeEJB was marked as NotSupported.
>> >>> >
>> >>> > As I mentioned earlier, this was recognized by the Geronimo
>> 1.1.1
>> >>> > container; however, it looks like the Geronimo 2.0 container is
>> >>> not
>> >>> > picking this up.
>> >>> >
>> >>> > A look at some of the OpenEJB trace information seems to
>> confirm
>> >>> > this...
>> >>> >
>> >>> > 22:11:51,437 INFO [OpenEJB] invoking method resetTrade on ejb/
>> >>> > TradeEJB with identity null
>> >>> > 22:11:51,437 INFO [Transaction] TX Required: Started
>> transaction
>> >>> >
>> org.apache.geronimo.transaction.manager.TransactionImpl@240a240a
>> >>> > 22:11:51,437 TRACE [SinglePoolConnectionInterceptor] Supplying
>> >>> > pooled connection MCI:
>> >>> >
>> >>>
>> org.apache.geronimo.connector.outbound.ManagedConnectionInfo@183e183
>> >>> e
>> >>> > MC: org.tranql.connector.jdbc.ManagedXAConnection@29fa29fa from
>> >>> > pool:
>> >>> >
>> >>>
>> org.apache.geronimo.connector.outbound.SinglePoolConnectionIntercept
>> >>> or
>> >>> > @56525652
>> >>> > 22:11:51,437 TRACE [TransactionCachingInterceptor] supplying
>> >>> > connection from pool null for managed connection
>> >>> > org.tranql.connector.jdbc.ManagedXAConnection@29fa29fa to tx
>> >>> > caching interceptor
>> >>> >
>> >>>
>> org.apache.geronimo.connector.outbound.TransactionCachingInterceptor
>> >>> @5
>> >>> > c005c00
>> >>> > 22:11:51,546 ERROR [Log] Error: Failed to reset Trade
>> >>> >
>> >>> > Just for reference, here is the exception that is being
>> thrown....
>> >>> >
>> >>> > 22:51:04,031 ERROR [Log] Error: Failed to reset Trade
>> >>> >
>> >>> > com.ibm.db2.jcc.b.SqlException: setAutoCommit(true)
>> >>> invalid
>> >>> > during global transaction
>> >>> > com.ibm.db2.jcc.b.SqlException : setAutoCommit(true) invalid
>> >>> during
>> >>> > global transaction
>> >>> > at com.ibm.db2.jcc.b.p.setAutoCommit(p.java:1152)
>> >>> > at com.ibm.db2.jcc.b.dc.setAutoCommit(dc.java:151)
>> >>> > at
>> >>> >
>> >>>
>> org.tranql.connector.jdbc.ManagedXAConnection.localTransactionCommit
>> >>> > (ManagedXAConnection.java :104)
>> >>> > at org.tranql.connector.AbstractManagedConnection
>> >>> > $LocalTransactionImpl.commit(AbstractManagedConnection.java :
>> 192)
>> >>> > at org.tranql.connector.jdbc.ConnectionHandle.commit
>> >>> > (ConnectionHandle.java:115)
>> >>> > at
>> >>> > org.apache.geronimo.samples.daytrader.direct.TradeDirect.commit
>> >>> > (TradeDirect.java :2044)
>> >>> > at
>> >>> >
>> >>>
>> org.apache.geronimo.samples.daytrader.direct.TradeDirect.resetTrade
>> >>> > (TradeDirect.java :1964)
>> >>> > at
>> >>> > org.apache.geronimo.samples.daytrader.ejb.TradeBean.resetTrade
>> >>> > (TradeBean.java:931)
>> >>> > at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native
>> >>> Method)
>> >>> > at sun.reflect.NativeMethodAccessorImpl.invoke
>> >>> > (NativeMethodAccessorImpl.java :64)
>> >>> > at sun.reflect.DelegatingMethodAccessorImpl.invoke
>> >>> > (DelegatingMethodAccessorImpl.java:43)
>> >>> > at java.lang.reflect.Method.invoke(Method.java:615)
>> >>> > at
>> >>> > org.apache.openejb.core.interceptor.ReflectionInvocationContext
>> >>> > $Invocation.invoke (ReflectionInvocationContext.java:146)
>> >>> > at
>> >>> >
>> >>>
>> org.apache.openejb.core.interceptor.ReflectionInvocationContext.proc
>> >>> ee
>> >>> > d(ReflectionInvocationContext.java:129)
>> >>> > at
>> >>> > org.apache.openejb.core.interceptor.InterceptorStack.invoke
>> >>> > (InterceptorStack.java :67)
>> >>> > at
>> >>> > org.apache.openejb.core.stateless.StatelessContainer._invoke
>> >>> > (StatelessContainer.java :203)
>> >>> > at
>> >>> > org.apache.openejb.core.stateless.StatelessContainer.invoke
>> >>> > (StatelessContainer.java :165)
>> >>> > ...
>> >>> >
>> >>> > Anyone have any thoughts on this one?
>> >>> >
>> >>> > Chris
>> >>> >
>> >>> > --
>> >>> > "I say never be complete, I say stop being perfect, I say
>> let...
>> >>> > lets evolve, let the chips fall where they may." - Tyler Durden
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> "I say never be complete, I say stop being perfect, I say let...
>> >>> lets evolve, let the chips fall where they may." - Tyler Durden
>> >>
>> >
>> >
>>
>>
>>
>>
>> --
>> "I say never be complete, I say stop being perfect, I say let...
>> lets evolve, let the chips fall where they may." - Tyler Durden
>
>
Re: Problems with method level container transactions in Geronimo 2.0 / OpenEJB
Posted by David Blevins <da...@visi.com>.
On Aug 1, 2007, at 1:49 PM, Christopher Blythe wrote:
> David...
>
> Do you have a JIRA for this yet?
Added one here http://issues.apache.org/jira/browse/OPENEJB-623
-David
>
>
>
> On 8/1/07, David Blevins <david.blevins@visi.com > wrote:That's the
> info I was looking for. I'll fix this.
>
> -David
>
> On Aug 1, 2007, at 9:03 AM, David Jencks wrote:
>
> > And section 13.3.7.2.1 very clearly states in great detail that
> > more specific xml overrides less specific xml. So IMO there's a
> > bug in openejb's current behavior.
> >
> > thanks
> > david jencks
> > On Aug 1, 2007, at 9:00 AM, David Jencks wrote:
> >
> >> The spec is clear about this case anyway, on p 336 it says
> >>
> >> Atransactionattributemaybespecifiedonamethodof thebeanclass
> >> tooverridethetransaction
> >> attribute value explicitly or implicitly specified on the bean
> class.
> >>
> >>
> >> thanks
> >> david jencks
> >>
> >> On Aug 1, 2007, at 5:17 AM, Christopher Blythe wrote:
> >>
> >>> David...
> >>>
> >>> Any idea how this will be handled in EJB 3 beans when the
> >>> transaction attributes are defined in the annotations? If I were
> >>> to define a transaction annotation for the whole bean and another
> >>> for an individual method, would the method level attribute be
> >>> ignored?
> >>>
> >>> Chris
> >>>
> >>> On 8/1/07, David Blevins < david.blevins@visi.com> wrote: On Jul
> >>> 25, 2007, at 7:57 PM, Christopher Blythe wrote:
> >>>
> >>> > I was working on DayTrader 2.0 when I found that the resetTrade
> >>> > method for all of the runtime modes (with the exception of
> Direct
> >>> > mode) would fail. I went back and deploy DayTrader 1.2 on GMO
> 2.0
> >>> > and noticed the same behavior. I then went back and deploy DT
> 1.2
> >>> > on GMO 1.1.1 and resetTrade worked for EJB mode like a champ.
> >>> >
> >>> > If you look in the ejb-jar.xml and check out the container
> >>> > transactions, you see the following...
> >>> >
> >>> > <container-transaction>
> >>> > <method>
> >>> > <ejb-name>TradeEJB</ejb-name>
> >>> > <method-intf>Remote</method-intf>
> >>> > <method-name>resetTrade</method-name>
> >>> > <method-params>
> >>> > <method-param>boolean</method-param>
> >>> > </method-params>
> >>> > </method>
> >>> > ...
> >>> > <trans-attribute>NotSupported</trans-attribute>
> >>> > </container-transaction>
> >>> >
> >>> > <container-transaction>
> >>> > ...
> >>> > <method>
> >>> > <ejb-name>TradeEJB</ejb-name>
> >>> > <method-name>*</method-name>
> >>> > </method>
> >>> > ...
> >>> > <trans-attribute>Required</trans-attribute>
> >>> > </container-transaction>
> >>>
> >>> Took me a couple hours to dig through this but basically what is
> >>> happening is that the second transaction attribute declaration for
> >>> TradeEJB (method "*") is essentially overwriting the first (method
> >>> "resetTrade(boolean)). These are processed in the order they are
> >>> declared so fixing it should be as easy as moving the "resetTrade
> >>> (boolean)" declaration to be after the "*" declaration.
> >>>
> >>> If you know of a part of the EJB spec that is relevant I'm
> >>> definitely
> >>> all ears -- as far as I know it's valid to process them in the
> order
> >>> they are declared.
> >>>
> >>> For the future (not 2.0) and provided it isn't explicitly
> prohibited
> >>> by the spec, we could possibly order the container-transaction
> >>> declarations for an ejb from least specific to most specific and
> >>> process them that way -- like we do for interceptor-bindings. If
> >>> you
> >>> had some time to do some leg work on digging through the spec
> that'd
> >>> be great.
> >>>
> >>> -David
> >>>
> >>>
> >>> > The impl for resetTrade in the TradeEJB session bean calls to
> the
> >>> > TradeDirect code in order to perform the reset. The TradeDirect
> >>> > code manages the transaction commits on its own. That is why the
> >>> > resetTrade method in TradeEJB was marked as NotSupported.
> >>> >
> >>> > As I mentioned earlier, this was recognized by the Geronimo
> 1.1.1
> >>> > container; however, it looks like the Geronimo 2.0 container is
> >>> not
> >>> > picking this up.
> >>> >
> >>> > A look at some of the OpenEJB trace information seems to confirm
> >>> > this...
> >>> >
> >>> > 22:11:51,437 INFO [OpenEJB] invoking method resetTrade on ejb/
> >>> > TradeEJB with identity null
> >>> > 22:11:51,437 INFO [Transaction] TX Required: Started
> transaction
> >>> > org.apache.geronimo.transaction.manager.TransactionImpl@240a240a
> >>> > 22:11:51,437 TRACE [SinglePoolConnectionInterceptor] Supplying
> >>> > pooled connection MCI:
> >>> >
> >>>
> org.apache.geronimo.connector.outbound.ManagedConnectionInfo@183e183
> >>> e
> >>> > MC: org.tranql.connector.jdbc.ManagedXAConnection@29fa29fa from
> >>> > pool:
> >>> >
> >>>
> org.apache.geronimo.connector.outbound.SinglePoolConnectionIntercept
> >>> or
> >>> > @56525652
> >>> > 22:11:51,437 TRACE [TransactionCachingInterceptor] supplying
> >>> > connection from pool null for managed connection
> >>> > org.tranql.connector.jdbc.ManagedXAConnection@29fa29fa to tx
> >>> > caching interceptor
> >>> >
> >>>
> org.apache.geronimo.connector.outbound.TransactionCachingInterceptor
> >>> @5
> >>> > c005c00
> >>> > 22:11:51,546 ERROR [Log] Error: Failed to reset Trade
> >>> >
> >>> > Just for reference, here is the exception that is being
> thrown....
> >>> >
> >>> > 22:51:04,031 ERROR [Log] Error: Failed to reset Trade
> >>> >
> >>> > com.ibm.db2.jcc.b.SqlException: setAutoCommit(true)
> >>> invalid
> >>> > during global transaction
> >>> > com.ibm.db2.jcc.b.SqlException : setAutoCommit(true) invalid
> >>> during
> >>> > global transaction
> >>> > at com.ibm.db2.jcc.b.p.setAutoCommit(p.java:1152)
> >>> > at com.ibm.db2.jcc.b.dc.setAutoCommit(dc.java:151)
> >>> > at
> >>> >
> >>>
> org.tranql.connector.jdbc.ManagedXAConnection.localTransactionCommit
> >>> > (ManagedXAConnection.java :104)
> >>> > at org.tranql.connector.AbstractManagedConnection
> >>> > $LocalTransactionImpl.commit(AbstractManagedConnection.java :
> 192)
> >>> > at org.tranql.connector.jdbc.ConnectionHandle.commit
> >>> > (ConnectionHandle.java:115)
> >>> > at
> >>> > org.apache.geronimo.samples.daytrader.direct.TradeDirect.commit
> >>> > (TradeDirect.java :2044)
> >>> > at
> >>> >
> >>>
> org.apache.geronimo.samples.daytrader.direct.TradeDirect.resetTrade
> >>> > (TradeDirect.java :1964)
> >>> > at
> >>> > org.apache.geronimo.samples.daytrader.ejb.TradeBean.resetTrade
> >>> > (TradeBean.java:931)
> >>> > at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native
> >>> Method)
> >>> > at sun.reflect.NativeMethodAccessorImpl.invoke
> >>> > (NativeMethodAccessorImpl.java :64)
> >>> > at sun.reflect.DelegatingMethodAccessorImpl.invoke
> >>> > (DelegatingMethodAccessorImpl.java:43)
> >>> > at java.lang.reflect.Method.invoke(Method.java:615)
> >>> > at
> >>> > org.apache.openejb.core.interceptor.ReflectionInvocationContext
> >>> > $Invocation.invoke (ReflectionInvocationContext.java:146)
> >>> > at
> >>> >
> >>>
> org.apache.openejb.core.interceptor.ReflectionInvocationContext.proc
> >>> ee
> >>> > d(ReflectionInvocationContext.java:129)
> >>> > at
> >>> > org.apache.openejb.core.interceptor.InterceptorStack.invoke
> >>> > (InterceptorStack.java :67)
> >>> > at
> >>> > org.apache.openejb.core.stateless.StatelessContainer._invoke
> >>> > (StatelessContainer.java :203)
> >>> > at
> >>> > org.apache.openejb.core.stateless.StatelessContainer.invoke
> >>> > (StatelessContainer.java :165)
> >>> > ...
> >>> >
> >>> > Anyone have any thoughts on this one?
> >>> >
> >>> > Chris
> >>> >
> >>> > --
> >>> > "I say never be complete, I say stop being perfect, I say let...
> >>> > lets evolve, let the chips fall where they may." - Tyler Durden
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> "I say never be complete, I say stop being perfect, I say let...
> >>> lets evolve, let the chips fall where they may." - Tyler Durden
> >>
> >
> >
>
>
>
>
> --
> "I say never be complete, I say stop being perfect, I say let...
> lets evolve, let the chips fall where they may." - Tyler Durden
Re: Problems with method level container transactions in Geronimo 2.0 / OpenEJB
Posted by Christopher Blythe <cj...@gmail.com>.
David...
Do you have a JIRA for this yet?
On 8/1/07, David Blevins <da...@visi.com> wrote:
>
> That's the info I was looking for. I'll fix this.
>
> -David
>
> On Aug 1, 2007, at 9:03 AM, David Jencks wrote:
>
> > And section 13.3.7.2.1 very clearly states in great detail that
> > more specific xml overrides less specific xml. So IMO there's a
> > bug in openejb's current behavior.
> >
> > thanks
> > david jencks
> > On Aug 1, 2007, at 9:00 AM, David Jencks wrote:
> >
> >> The spec is clear about this case anyway, on p 336 it says
> >>
> >> Atransactionattributemaybespecifiedonamethodof thebeanclass
> >> tooverridethetransaction
> >> attribute value explicitly or implicitly specified on the bean class.
> >>
> >>
> >> thanks
> >> david jencks
> >>
> >> On Aug 1, 2007, at 5:17 AM, Christopher Blythe wrote:
> >>
> >>> David...
> >>>
> >>> Any idea how this will be handled in EJB 3 beans when the
> >>> transaction attributes are defined in the annotations? If I were
> >>> to define a transaction annotation for the whole bean and another
> >>> for an individual method, would the method level attribute be
> >>> ignored?
> >>>
> >>> Chris
> >>>
> >>> On 8/1/07, David Blevins <da...@visi.com> wrote: On Jul
> >>> 25, 2007, at 7:57 PM, Christopher Blythe wrote:
> >>>
> >>> > I was working on DayTrader 2.0 when I found that the resetTrade
> >>> > method for all of the runtime modes (with the exception of Direct
> >>> > mode) would fail. I went back and deploy DayTrader 1.2 on GMO 2.0
> >>> > and noticed the same behavior. I then went back and deploy DT 1.2
> >>> > on GMO 1.1.1 and resetTrade worked for EJB mode like a champ.
> >>> >
> >>> > If you look in the ejb-jar.xml and check out the container
> >>> > transactions, you see the following...
> >>> >
> >>> > <container-transaction>
> >>> > <method>
> >>> > <ejb-name>TradeEJB</ejb-name>
> >>> > <method-intf>Remote</method-intf>
> >>> > <method-name>resetTrade</method-name>
> >>> > <method-params>
> >>> > <method-param>boolean</method-param>
> >>> > </method-params>
> >>> > </method>
> >>> > ...
> >>> > <trans-attribute>NotSupported</trans-attribute>
> >>> > </container-transaction>
> >>> >
> >>> > <container-transaction>
> >>> > ...
> >>> > <method>
> >>> > <ejb-name>TradeEJB</ejb-name>
> >>> > <method-name>*</method-name>
> >>> > </method>
> >>> > ...
> >>> > <trans-attribute>Required</trans-attribute>
> >>> > </container-transaction>
> >>>
> >>> Took me a couple hours to dig through this but basically what is
> >>> happening is that the second transaction attribute declaration for
> >>> TradeEJB (method "*") is essentially overwriting the first (method
> >>> "resetTrade(boolean)). These are processed in the order they are
> >>> declared so fixing it should be as easy as moving the "resetTrade
> >>> (boolean)" declaration to be after the "*" declaration.
> >>>
> >>> If you know of a part of the EJB spec that is relevant I'm
> >>> definitely
> >>> all ears -- as far as I know it's valid to process them in the order
> >>> they are declared.
> >>>
> >>> For the future (not 2.0) and provided it isn't explicitly prohibited
> >>> by the spec, we could possibly order the container-transaction
> >>> declarations for an ejb from least specific to most specific and
> >>> process them that way -- like we do for interceptor-bindings. If
> >>> you
> >>> had some time to do some leg work on digging through the spec that'd
> >>> be great.
> >>>
> >>> -David
> >>>
> >>>
> >>> > The impl for resetTrade in the TradeEJB session bean calls to the
> >>> > TradeDirect code in order to perform the reset. The TradeDirect
> >>> > code manages the transaction commits on its own. That is why the
> >>> > resetTrade method in TradeEJB was marked as NotSupported.
> >>> >
> >>> > As I mentioned earlier, this was recognized by the Geronimo 1.1.1
> >>> > container; however, it looks like the Geronimo 2.0 container is
> >>> not
> >>> > picking this up.
> >>> >
> >>> > A look at some of the OpenEJB trace information seems to confirm
> >>> > this...
> >>> >
> >>> > 22:11:51,437 INFO [OpenEJB] invoking method resetTrade on ejb/
> >>> > TradeEJB with identity null
> >>> > 22:11:51,437 INFO [Transaction] TX Required: Started transaction
> >>> > org.apache.geronimo.transaction.manager.TransactionImpl@240a240a
> >>> > 22:11:51,437 TRACE [SinglePoolConnectionInterceptor] Supplying
> >>> > pooled connection MCI:
> >>> >
> >>> org.apache.geronimo.connector.outbound.ManagedConnectionInfo@183e183
> >>> e
> >>> > MC: org.tranql.connector.jdbc.ManagedXAConnection@29fa29fa from
> >>> > pool:
> >>> >
> >>> org.apache.geronimo.connector.outbound.SinglePoolConnectionIntercept
> >>> or
> >>> > @56525652
> >>> > 22:11:51,437 TRACE [TransactionCachingInterceptor] supplying
> >>> > connection from pool null for managed connection
> >>> > org.tranql.connector.jdbc.ManagedXAConnection@29fa29fa to tx
> >>> > caching interceptor
> >>> >
> >>> org.apache.geronimo.connector.outbound.TransactionCachingInterceptor
> >>> @5
> >>> > c005c00
> >>> > 22:11:51,546 ERROR [Log] Error: Failed to reset Trade
> >>> >
> >>> > Just for reference, here is the exception that is being thrown....
> >>> >
> >>> > 22:51:04,031 ERROR [Log] Error: Failed to reset Trade
> >>> >
> >>> > com.ibm.db2.jcc.b.SqlException: setAutoCommit(true)
> >>> invalid
> >>> > during global transaction
> >>> > com.ibm.db2.jcc.b.SqlException : setAutoCommit(true) invalid
> >>> during
> >>> > global transaction
> >>> > at com.ibm.db2.jcc.b.p.setAutoCommit(p.java:1152)
> >>> > at com.ibm.db2.jcc.b.dc.setAutoCommit(dc.java:151)
> >>> > at
> >>> >
> >>> org.tranql.connector.jdbc.ManagedXAConnection.localTransactionCommit
> >>> > (ManagedXAConnection.java :104)
> >>> > at org.tranql.connector.AbstractManagedConnection
> >>> > $LocalTransactionImpl.commit(AbstractManagedConnection.java :192)
> >>> > at org.tranql.connector.jdbc.ConnectionHandle.commit
> >>> > (ConnectionHandle.java:115)
> >>> > at
> >>> > org.apache.geronimo.samples.daytrader.direct.TradeDirect.commit
> >>> > (TradeDirect.java :2044)
> >>> > at
> >>> >
> >>> org.apache.geronimo.samples.daytrader.direct.TradeDirect.resetTrade
> >>> > (TradeDirect.java:1964)
> >>> > at
> >>> > org.apache.geronimo.samples.daytrader.ejb.TradeBean.resetTrade
> >>> > (TradeBean.java:931)
> >>> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
> >>> Method)
> >>> > at sun.reflect.NativeMethodAccessorImpl.invoke
> >>> > (NativeMethodAccessorImpl.java :64)
> >>> > at sun.reflect.DelegatingMethodAccessorImpl.invoke
> >>> > (DelegatingMethodAccessorImpl.java:43)
> >>> > at java.lang.reflect.Method.invoke(Method.java:615)
> >>> > at
> >>> > org.apache.openejb.core.interceptor.ReflectionInvocationContext
> >>> > $Invocation.invoke (ReflectionInvocationContext.java:146)
> >>> > at
> >>> >
> >>> org.apache.openejb.core.interceptor.ReflectionInvocationContext.proc
> >>> ee
> >>> > d(ReflectionInvocationContext.java:129)
> >>> > at
> >>> > org.apache.openejb.core.interceptor.InterceptorStack.invoke
> >>> > (InterceptorStack.java:67)
> >>> > at
> >>> > org.apache.openejb.core.stateless.StatelessContainer._invoke
> >>> > (StatelessContainer.java :203)
> >>> > at
> >>> > org.apache.openejb.core.stateless.StatelessContainer.invoke
> >>> > (StatelessContainer.java :165)
> >>> > ...
> >>> >
> >>> > Anyone have any thoughts on this one?
> >>> >
> >>> > Chris
> >>> >
> >>> > --
> >>> > "I say never be complete, I say stop being perfect, I say let...
> >>> > lets evolve, let the chips fall where they may." - Tyler Durden
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> "I say never be complete, I say stop being perfect, I say let...
> >>> lets evolve, let the chips fall where they may." - Tyler Durden
> >>
> >
> >
>
>
--
"I say never be complete, I say stop being perfect, I say let... lets
evolve, let the chips fall where they may." - Tyler Durden
Re: Problems with method level container transactions in Geronimo 2.0 / OpenEJB
Posted by David Blevins <da...@visi.com>.
That's the info I was looking for. I'll fix this.
-David
On Aug 1, 2007, at 9:03 AM, David Jencks wrote:
> And section 13.3.7.2.1 very clearly states in great detail that
> more specific xml overrides less specific xml. So IMO there's a
> bug in openejb's current behavior.
>
> thanks
> david jencks
> On Aug 1, 2007, at 9:00 AM, David Jencks wrote:
>
>> The spec is clear about this case anyway, on p 336 it says
>>
>> Atransactionattributemaybespecifiedonamethodof thebeanclass
>> tooverridethetransaction
>> attribute value explicitly or implicitly specified on the bean class.
>>
>>
>> thanks
>> david jencks
>>
>> On Aug 1, 2007, at 5:17 AM, Christopher Blythe wrote:
>>
>>> David...
>>>
>>> Any idea how this will be handled in EJB 3 beans when the
>>> transaction attributes are defined in the annotations? If I were
>>> to define a transaction annotation for the whole bean and another
>>> for an individual method, would the method level attribute be
>>> ignored?
>>>
>>> Chris
>>>
>>> On 8/1/07, David Blevins <da...@visi.com> wrote: On Jul
>>> 25, 2007, at 7:57 PM, Christopher Blythe wrote:
>>>
>>> > I was working on DayTrader 2.0 when I found that the resetTrade
>>> > method for all of the runtime modes (with the exception of Direct
>>> > mode) would fail. I went back and deploy DayTrader 1.2 on GMO 2.0
>>> > and noticed the same behavior. I then went back and deploy DT 1.2
>>> > on GMO 1.1.1 and resetTrade worked for EJB mode like a champ.
>>> >
>>> > If you look in the ejb-jar.xml and check out the container
>>> > transactions, you see the following...
>>> >
>>> > <container-transaction>
>>> > <method>
>>> > <ejb-name>TradeEJB</ejb-name>
>>> > <method-intf>Remote</method-intf>
>>> > <method-name>resetTrade</method-name>
>>> > <method-params>
>>> > <method-param>boolean</method-param>
>>> > </method-params>
>>> > </method>
>>> > ...
>>> > <trans-attribute>NotSupported</trans-attribute>
>>> > </container-transaction>
>>> >
>>> > <container-transaction>
>>> > ...
>>> > <method>
>>> > <ejb-name>TradeEJB</ejb-name>
>>> > <method-name>*</method-name>
>>> > </method>
>>> > ...
>>> > <trans-attribute>Required</trans-attribute>
>>> > </container-transaction>
>>>
>>> Took me a couple hours to dig through this but basically what is
>>> happening is that the second transaction attribute declaration for
>>> TradeEJB (method "*") is essentially overwriting the first (method
>>> "resetTrade(boolean)). These are processed in the order they are
>>> declared so fixing it should be as easy as moving the "resetTrade
>>> (boolean)" declaration to be after the "*" declaration.
>>>
>>> If you know of a part of the EJB spec that is relevant I'm
>>> definitely
>>> all ears -- as far as I know it's valid to process them in the order
>>> they are declared.
>>>
>>> For the future (not 2.0) and provided it isn't explicitly prohibited
>>> by the spec, we could possibly order the container-transaction
>>> declarations for an ejb from least specific to most specific and
>>> process them that way -- like we do for interceptor-bindings. If
>>> you
>>> had some time to do some leg work on digging through the spec that'd
>>> be great.
>>>
>>> -David
>>>
>>>
>>> > The impl for resetTrade in the TradeEJB session bean calls to the
>>> > TradeDirect code in order to perform the reset. The TradeDirect
>>> > code manages the transaction commits on its own. That is why the
>>> > resetTrade method in TradeEJB was marked as NotSupported.
>>> >
>>> > As I mentioned earlier, this was recognized by the Geronimo 1.1.1
>>> > container; however, it looks like the Geronimo 2.0 container is
>>> not
>>> > picking this up.
>>> >
>>> > A look at some of the OpenEJB trace information seems to confirm
>>> > this...
>>> >
>>> > 22:11:51,437 INFO [OpenEJB] invoking method resetTrade on ejb/
>>> > TradeEJB with identity null
>>> > 22:11:51,437 INFO [Transaction] TX Required: Started transaction
>>> > org.apache.geronimo.transaction.manager.TransactionImpl@240a240a
>>> > 22:11:51,437 TRACE [SinglePoolConnectionInterceptor] Supplying
>>> > pooled connection MCI:
>>> >
>>> org.apache.geronimo.connector.outbound.ManagedConnectionInfo@183e183
>>> e
>>> > MC: org.tranql.connector.jdbc.ManagedXAConnection@29fa29fa from
>>> > pool:
>>> >
>>> org.apache.geronimo.connector.outbound.SinglePoolConnectionIntercept
>>> or
>>> > @56525652
>>> > 22:11:51,437 TRACE [TransactionCachingInterceptor] supplying
>>> > connection from pool null for managed connection
>>> > org.tranql.connector.jdbc.ManagedXAConnection@29fa29fa to tx
>>> > caching interceptor
>>> >
>>> org.apache.geronimo.connector.outbound.TransactionCachingInterceptor
>>> @5
>>> > c005c00
>>> > 22:11:51,546 ERROR [Log] Error: Failed to reset Trade
>>> >
>>> > Just for reference, here is the exception that is being thrown....
>>> >
>>> > 22:51:04,031 ERROR [Log] Error: Failed to reset Trade
>>> >
>>> > com.ibm.db2.jcc.b.SqlException: setAutoCommit(true)
>>> invalid
>>> > during global transaction
>>> > com.ibm.db2.jcc.b.SqlException : setAutoCommit(true) invalid
>>> during
>>> > global transaction
>>> > at com.ibm.db2.jcc.b.p.setAutoCommit(p.java:1152)
>>> > at com.ibm.db2.jcc.b.dc.setAutoCommit(dc.java:151)
>>> > at
>>> >
>>> org.tranql.connector.jdbc.ManagedXAConnection.localTransactionCommit
>>> > (ManagedXAConnection.java :104)
>>> > at org.tranql.connector.AbstractManagedConnection
>>> > $LocalTransactionImpl.commit(AbstractManagedConnection.java :192)
>>> > at org.tranql.connector.jdbc.ConnectionHandle.commit
>>> > (ConnectionHandle.java:115)
>>> > at
>>> > org.apache.geronimo.samples.daytrader.direct.TradeDirect.commit
>>> > (TradeDirect.java :2044)
>>> > at
>>> >
>>> org.apache.geronimo.samples.daytrader.direct.TradeDirect.resetTrade
>>> > (TradeDirect.java:1964)
>>> > at
>>> > org.apache.geronimo.samples.daytrader.ejb.TradeBean.resetTrade
>>> > (TradeBean.java:931)
>>> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
>>> Method)
>>> > at sun.reflect.NativeMethodAccessorImpl.invoke
>>> > (NativeMethodAccessorImpl.java :64)
>>> > at sun.reflect.DelegatingMethodAccessorImpl.invoke
>>> > (DelegatingMethodAccessorImpl.java:43)
>>> > at java.lang.reflect.Method.invoke(Method.java:615)
>>> > at
>>> > org.apache.openejb.core.interceptor.ReflectionInvocationContext
>>> > $Invocation.invoke (ReflectionInvocationContext.java:146)
>>> > at
>>> >
>>> org.apache.openejb.core.interceptor.ReflectionInvocationContext.proc
>>> ee
>>> > d(ReflectionInvocationContext.java:129)
>>> > at
>>> > org.apache.openejb.core.interceptor.InterceptorStack.invoke
>>> > (InterceptorStack.java:67)
>>> > at
>>> > org.apache.openejb.core.stateless.StatelessContainer._invoke
>>> > (StatelessContainer.java :203)
>>> > at
>>> > org.apache.openejb.core.stateless.StatelessContainer.invoke
>>> > (StatelessContainer.java :165)
>>> > ...
>>> >
>>> > Anyone have any thoughts on this one?
>>> >
>>> > Chris
>>> >
>>> > --
>>> > "I say never be complete, I say stop being perfect, I say let...
>>> > lets evolve, let the chips fall where they may." - Tyler Durden
>>>
>>>
>>>
>>>
>>> --
>>> "I say never be complete, I say stop being perfect, I say let...
>>> lets evolve, let the chips fall where they may." - Tyler Durden
>>
>
>
Re: Problems with method level container transactions in Geronimo 2.0 / OpenEJB
Posted by David Jencks <da...@yahoo.com>.
And section 13.3.7.2.1 very clearly states in great detail that more
specific xml overrides less specific xml. So IMO there's a bug in
openejb's current behavior.
thanks
david jencks
On Aug 1, 2007, at 9:00 AM, David Jencks wrote:
> The spec is clear about this case anyway, on p 336 it says
>
> Atransactionattributemaybespecifiedonamethodof thebeanclass
> tooverridethetransaction
> attribute value explicitly or implicitly specified on the bean class.
>
>
> thanks
> david jencks
>
> On Aug 1, 2007, at 5:17 AM, Christopher Blythe wrote:
>
>> David...
>>
>> Any idea how this will be handled in EJB 3 beans when the
>> transaction attributes are defined in the annotations? If I were
>> to define a transaction annotation for the whole bean and another
>> for an individual method, would the method level attribute be
>> ignored?
>>
>> Chris
>>
>> On 8/1/07, David Blevins <da...@visi.com> wrote: On Jul
>> 25, 2007, at 7:57 PM, Christopher Blythe wrote:
>>
>> > I was working on DayTrader 2.0 when I found that the resetTrade
>> > method for all of the runtime modes (with the exception of Direct
>> > mode) would fail. I went back and deploy DayTrader 1.2 on GMO 2.0
>> > and noticed the same behavior. I then went back and deploy DT 1.2
>> > on GMO 1.1.1 and resetTrade worked for EJB mode like a champ.
>> >
>> > If you look in the ejb-jar.xml and check out the container
>> > transactions, you see the following...
>> >
>> > <container-transaction>
>> > <method>
>> > <ejb-name>TradeEJB</ejb-name>
>> > <method-intf>Remote</method-intf>
>> > <method-name>resetTrade</method-name>
>> > <method-params>
>> > <method-param>boolean</method-param>
>> > </method-params>
>> > </method>
>> > ...
>> > <trans-attribute>NotSupported</trans-attribute>
>> > </container-transaction>
>> >
>> > <container-transaction>
>> > ...
>> > <method>
>> > <ejb-name>TradeEJB</ejb-name>
>> > <method-name>*</method-name>
>> > </method>
>> > ...
>> > <trans-attribute>Required</trans-attribute>
>> > </container-transaction>
>>
>> Took me a couple hours to dig through this but basically what is
>> happening is that the second transaction attribute declaration for
>> TradeEJB (method "*") is essentially overwriting the first (method
>> "resetTrade(boolean)). These are processed in the order they are
>> declared so fixing it should be as easy as moving the "resetTrade
>> (boolean)" declaration to be after the "*" declaration.
>>
>> If you know of a part of the EJB spec that is relevant I'm definitely
>> all ears -- as far as I know it's valid to process them in the order
>> they are declared.
>>
>> For the future (not 2.0) and provided it isn't explicitly prohibited
>> by the spec, we could possibly order the container-transaction
>> declarations for an ejb from least specific to most specific and
>> process them that way -- like we do for interceptor-bindings. If you
>> had some time to do some leg work on digging through the spec that'd
>> be great.
>>
>> -David
>>
>>
>> > The impl for resetTrade in the TradeEJB session bean calls to the
>> > TradeDirect code in order to perform the reset. The TradeDirect
>> > code manages the transaction commits on its own. That is why the
>> > resetTrade method in TradeEJB was marked as NotSupported.
>> >
>> > As I mentioned earlier, this was recognized by the Geronimo 1.1.1
>> > container; however, it looks like the Geronimo 2.0 container is not
>> > picking this up.
>> >
>> > A look at some of the OpenEJB trace information seems to confirm
>> > this...
>> >
>> > 22:11:51,437 INFO [OpenEJB] invoking method resetTrade on ejb/
>> > TradeEJB with identity null
>> > 22:11:51,437 INFO [Transaction] TX Required: Started transaction
>> > org.apache.geronimo.transaction.manager.TransactionImpl@240a240a
>> > 22:11:51,437 TRACE [SinglePoolConnectionInterceptor] Supplying
>> > pooled connection MCI:
>> >
>> org.apache.geronimo.connector.outbound.ManagedConnectionInfo@183e183e
>> > MC: org.tranql.connector.jdbc.ManagedXAConnection@29fa29fa from
>> > pool:
>> >
>> org.apache.geronimo.connector.outbound.SinglePoolConnectionIntercepto
>> r
>> > @56525652
>> > 22:11:51,437 TRACE [TransactionCachingInterceptor] supplying
>> > connection from pool null for managed connection
>> > org.tranql.connector.jdbc.ManagedXAConnection@29fa29fa to tx
>> > caching interceptor
>> >
>> org.apache.geronimo.connector.outbound.TransactionCachingInterceptor@
>> 5
>> > c005c00
>> > 22:11:51,546 ERROR [Log] Error: Failed to reset Trade
>> >
>> > Just for reference, here is the exception that is being thrown....
>> >
>> > 22:51:04,031 ERROR [Log] Error: Failed to reset Trade
>> >
>> > com.ibm.db2.jcc.b.SqlException: setAutoCommit(true) invalid
>> > during global transaction
>> > com.ibm.db2.jcc.b.SqlException : setAutoCommit(true) invalid during
>> > global transaction
>> > at com.ibm.db2.jcc.b.p.setAutoCommit(p.java:1152)
>> > at com.ibm.db2.jcc.b.dc.setAutoCommit(dc.java:151)
>> > at
>> >
>> org.tranql.connector.jdbc.ManagedXAConnection.localTransactionCommit
>> > (ManagedXAConnection.java :104)
>> > at org.tranql.connector.AbstractManagedConnection
>> > $LocalTransactionImpl.commit(AbstractManagedConnection.java :192)
>> > at org.tranql.connector.jdbc.ConnectionHandle.commit
>> > (ConnectionHandle.java:115)
>> > at
>> > org.apache.geronimo.samples.daytrader.direct.TradeDirect.commit
>> > (TradeDirect.java :2044)
>> > at
>> > org.apache.geronimo.samples.daytrader.direct.TradeDirect.resetTrade
>> > (TradeDirect.java:1964)
>> > at
>> > org.apache.geronimo.samples.daytrader.ejb.TradeBean.resetTrade
>> > (TradeBean.java:931)
>> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
>> Method)
>> > at sun.reflect.NativeMethodAccessorImpl.invoke
>> > (NativeMethodAccessorImpl.java :64)
>> > at sun.reflect.DelegatingMethodAccessorImpl.invoke
>> > (DelegatingMethodAccessorImpl.java:43)
>> > at java.lang.reflect.Method.invoke(Method.java:615)
>> > at
>> > org.apache.openejb.core.interceptor.ReflectionInvocationContext
>> > $Invocation.invoke (ReflectionInvocationContext.java:146)
>> > at
>> >
>> org.apache.openejb.core.interceptor.ReflectionInvocationContext.proce
>> e
>> > d(ReflectionInvocationContext.java:129)
>> > at
>> > org.apache.openejb.core.interceptor.InterceptorStack.invoke
>> > (InterceptorStack.java:67)
>> > at
>> > org.apache.openejb.core.stateless.StatelessContainer._invoke
>> > (StatelessContainer.java :203)
>> > at
>> > org.apache.openejb.core.stateless.StatelessContainer.invoke
>> > (StatelessContainer.java :165)
>> > ...
>> >
>> > Anyone have any thoughts on this one?
>> >
>> > Chris
>> >
>> > --
>> > "I say never be complete, I say stop being perfect, I say let...
>> > lets evolve, let the chips fall where they may." - Tyler Durden
>>
>>
>>
>>
>> --
>> "I say never be complete, I say stop being perfect, I say let...
>> lets evolve, let the chips fall where they may." - Tyler Durden
>
Re: Problems with method level container transactions in Geronimo 2.0 / OpenEJB
Posted by David Jencks <da...@yahoo.com>.
The spec is clear about this case anyway, on p 336 it says
Atransactionattributemaybespecifiedonamethodof thebeanclass
tooverridethetransaction
attribute value explicitly or implicitly specified on the bean class.
thanks
david jencks
On Aug 1, 2007, at 5:17 AM, Christopher Blythe wrote:
> David...
>
> Any idea how this will be handled in EJB 3 beans when the
> transaction attributes are defined in the annotations? If I were to
> define a transaction annotation for the whole bean and another for
> an individual method, would the method level attribute be ignored?
>
> Chris
>
> On 8/1/07, David Blevins <da...@visi.com> wrote:
> On Jul 25, 2007, at 7:57 PM, Christopher Blythe wrote:
>
> > I was working on DayTrader 2.0 when I found that the resetTrade
> > method for all of the runtime modes (with the exception of Direct
> > mode) would fail. I went back and deploy DayTrader 1.2 on GMO 2.0
> > and noticed the same behavior. I then went back and deploy DT 1.2
> > on GMO 1.1.1 and resetTrade worked for EJB mode like a champ.
> >
> > If you look in the ejb-jar.xml and check out the container
> > transactions, you see the following...
> >
> > <container-transaction>
> > <method>
> > <ejb-name>TradeEJB</ejb-name>
> > <method-intf>Remote</method-intf>
> > <method-name>resetTrade</method-name>
> > <method-params>
> > <method-param>boolean</method-param>
> > </method-params>
> > </method>
> > ...
> > <trans-attribute>NotSupported</trans-attribute>
> > </container-transaction>
> >
> > <container-transaction>
> > ...
> > <method>
> > <ejb-name>TradeEJB</ejb-name>
> > <method-name>*</method-name>
> > </method>
> > ...
> > <trans-attribute>Required</trans-attribute>
> > </container-transaction>
>
> Took me a couple hours to dig through this but basically what is
> happening is that the second transaction attribute declaration for
> TradeEJB (method "*") is essentially overwriting the first (method
> "resetTrade(boolean)). These are processed in the order they are
> declared so fixing it should be as easy as moving the "resetTrade
> (boolean)" declaration to be after the "*" declaration.
>
> If you know of a part of the EJB spec that is relevant I'm definitely
> all ears -- as far as I know it's valid to process them in the order
> they are declared.
>
> For the future (not 2.0) and provided it isn't explicitly prohibited
> by the spec, we could possibly order the container-transaction
> declarations for an ejb from least specific to most specific and
> process them that way -- like we do for interceptor-bindings. If you
> had some time to do some leg work on digging through the spec that'd
> be great.
>
> -David
>
>
> > The impl for resetTrade in the TradeEJB session bean calls to the
> > TradeDirect code in order to perform the reset. The TradeDirect
> > code manages the transaction commits on its own. That is why the
> > resetTrade method in TradeEJB was marked as NotSupported.
> >
> > As I mentioned earlier, this was recognized by the Geronimo 1.1.1
> > container; however, it looks like the Geronimo 2.0 container is not
> > picking this up.
> >
> > A look at some of the OpenEJB trace information seems to confirm
> > this...
> >
> > 22:11:51,437 INFO [OpenEJB] invoking method resetTrade on ejb/
> > TradeEJB with identity null
> > 22:11:51,437 INFO [Transaction] TX Required: Started transaction
> > org.apache.geronimo.transaction.manager.TransactionImpl@240a240a
> > 22:11:51,437 TRACE [SinglePoolConnectionInterceptor] Supplying
> > pooled connection MCI:
> >
> org.apache.geronimo.connector.outbound.ManagedConnectionInfo@183e183e
> > MC: org.tranql.connector.jdbc.ManagedXAConnection@29fa29fa from
> > pool:
> >
> org.apache.geronimo.connector.outbound.SinglePoolConnectionInterceptor
> > @56525652
> > 22:11:51,437 TRACE [TransactionCachingInterceptor] supplying
> > connection from pool null for managed connection
> > org.tranql.connector.jdbc.ManagedXAConnection@29fa29fa to tx
> > caching interceptor
> >
> org.apache.geronimo.connector.outbound.TransactionCachingInterceptor@5
> > c005c00
> > 22:11:51,546 ERROR [Log] Error: Failed to reset Trade
> >
> > Just for reference, here is the exception that is being thrown....
> >
> > 22:51:04,031 ERROR [Log] Error: Failed to reset Trade
> >
> > com.ibm.db2.jcc.b.SqlException: setAutoCommit(true) invalid
> > during global transaction
> > com.ibm.db2.jcc.b.SqlException : setAutoCommit(true) invalid during
> > global transaction
> > at com.ibm.db2.jcc.b.p.setAutoCommit(p.java:1152)
> > at com.ibm.db2.jcc.b.dc.setAutoCommit(dc.java:151)
> > at
> > org.tranql.connector.jdbc.ManagedXAConnection.localTransactionCommit
> > (ManagedXAConnection.java :104)
> > at org.tranql.connector.AbstractManagedConnection
> > $LocalTransactionImpl.commit(AbstractManagedConnection.java :192)
> > at org.tranql.connector.jdbc.ConnectionHandle.commit
> > (ConnectionHandle.java:115)
> > at
> > org.apache.geronimo.samples.daytrader.direct.TradeDirect.commit
> > (TradeDirect.java :2044)
> > at
> > org.apache.geronimo.samples.daytrader.direct.TradeDirect.resetTrade
> > (TradeDirect.java:1964)
> > at
> > org.apache.geronimo.samples.daytrader.ejb.TradeBean.resetTrade
> > (TradeBean.java:931)
> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> > at sun.reflect.NativeMethodAccessorImpl.invoke
> > (NativeMethodAccessorImpl.java :64)
> > at sun.reflect.DelegatingMethodAccessorImpl.invoke
> > (DelegatingMethodAccessorImpl.java:43)
> > at java.lang.reflect.Method.invoke(Method.java:615)
> > at
> > org.apache.openejb.core.interceptor.ReflectionInvocationContext
> > $Invocation.invoke (ReflectionInvocationContext.java:146)
> > at
> >
> org.apache.openejb.core.interceptor.ReflectionInvocationContext.procee
> > d(ReflectionInvocationContext.java:129)
> > at
> > org.apache.openejb.core.interceptor.InterceptorStack.invoke
> > (InterceptorStack.java:67)
> > at
> > org.apache.openejb.core.stateless.StatelessContainer._invoke
> > (StatelessContainer.java :203)
> > at
> > org.apache.openejb.core.stateless.StatelessContainer.invoke
> > (StatelessContainer.java :165)
> > ...
> >
> > Anyone have any thoughts on this one?
> >
> > Chris
> >
> > --
> > "I say never be complete, I say stop being perfect, I say let...
> > lets evolve, let the chips fall where they may." - Tyler Durden
>
>
>
>
> --
> "I say never be complete, I say stop being perfect, I say let...
> lets evolve, let the chips fall where they may." - Tyler Durden
Re: Problems with method level container transactions in Geronimo 2.0 / OpenEJB
Posted by Christopher Blythe <cj...@gmail.com>.
David...
Any idea how this will be handled in EJB 3 beans when the transaction
attributes are defined in the annotations? If I were to define a transaction
annotation for the whole bean and another for an individual method, would
the method level attribute be ignored?
Chris
On 8/1/07, David Blevins <da...@visi.com> wrote:
>
> On Jul 25, 2007, at 7:57 PM, Christopher Blythe wrote:
>
> > I was working on DayTrader 2.0 when I found that the resetTrade
> > method for all of the runtime modes (with the exception of Direct
> > mode) would fail. I went back and deploy DayTrader 1.2 on GMO 2.0
> > and noticed the same behavior. I then went back and deploy DT 1.2
> > on GMO 1.1.1 and resetTrade worked for EJB mode like a champ.
> >
> > If you look in the ejb-jar.xml and check out the container
> > transactions, you see the following...
> >
> > <container-transaction>
> > <method>
> > <ejb-name>TradeEJB</ejb-name>
> > <method-intf>Remote</method-intf>
> > <method-name>resetTrade</method-name>
> > <method-params>
> > <method-param>boolean</method-param>
> > </method-params>
> > </method>
> > ...
> > <trans-attribute>NotSupported</trans-attribute>
> > </container-transaction>
> >
> > <container-transaction>
> > ...
> > <method>
> > <ejb-name>TradeEJB</ejb-name>
> > <method-name>*</method-name>
> > </method>
> > ...
> > <trans-attribute>Required</trans-attribute>
> > </container-transaction>
>
> Took me a couple hours to dig through this but basically what is
> happening is that the second transaction attribute declaration for
> TradeEJB (method "*") is essentially overwriting the first (method
> "resetTrade(boolean)). These are processed in the order they are
> declared so fixing it should be as easy as moving the "resetTrade
> (boolean)" declaration to be after the "*" declaration.
>
> If you know of a part of the EJB spec that is relevant I'm definitely
> all ears -- as far as I know it's valid to process them in the order
> they are declared.
>
> For the future (not 2.0) and provided it isn't explicitly prohibited
> by the spec, we could possibly order the container-transaction
> declarations for an ejb from least specific to most specific and
> process them that way -- like we do for interceptor-bindings. If you
> had some time to do some leg work on digging through the spec that'd
> be great.
>
> -David
>
>
> > The impl for resetTrade in the TradeEJB session bean calls to the
> > TradeDirect code in order to perform the reset. The TradeDirect
> > code manages the transaction commits on its own. That is why the
> > resetTrade method in TradeEJB was marked as NotSupported.
> >
> > As I mentioned earlier, this was recognized by the Geronimo 1.1.1
> > container; however, it looks like the Geronimo 2.0 container is not
> > picking this up.
> >
> > A look at some of the OpenEJB trace information seems to confirm
> > this...
> >
> > 22:11:51,437 INFO [OpenEJB] invoking method resetTrade on ejb/
> > TradeEJB with identity null
> > 22:11:51,437 INFO [Transaction] TX Required: Started transaction
> > org.apache.geronimo.transaction.manager.TransactionImpl@240a240a
> > 22:11:51,437 TRACE [SinglePoolConnectionInterceptor] Supplying
> > pooled connection MCI:
> > org.apache.geronimo.connector.outbound.ManagedConnectionInfo@183e183e
> > MC: org.tranql.connector.jdbc.ManagedXAConnection@29fa29fa from
> > pool:
> > org.apache.geronimo.connector.outbound.SinglePoolConnectionInterceptor
> > @56525652
> > 22:11:51,437 TRACE [TransactionCachingInterceptor] supplying
> > connection from pool null for managed connection
> > org.tranql.connector.jdbc.ManagedXAConnection@29fa29fa to tx
> > caching interceptor
> > org.apache.geronimo.connector.outbound.TransactionCachingInterceptor@5
> > c005c00
> > 22:11:51,546 ERROR [Log] Error: Failed to reset Trade
> >
> > Just for reference, here is the exception that is being thrown....
> >
> > 22:51:04,031 ERROR [Log] Error: Failed to reset Trade
> >
> > com.ibm.db2.jcc.b.SqlException: setAutoCommit(true) invalid
> > during global transaction
> > com.ibm.db2.jcc.b.SqlException: setAutoCommit(true) invalid during
> > global transaction
> > at com.ibm.db2.jcc.b.p.setAutoCommit(p.java:1152)
> > at com.ibm.db2.jcc.b.dc.setAutoCommit(dc.java:151)
> > at
> > org.tranql.connector.jdbc.ManagedXAConnection.localTransactionCommit
> > (ManagedXAConnection.java :104)
> > at org.tranql.connector.AbstractManagedConnection
> > $LocalTransactionImpl.commit(AbstractManagedConnection.java:192)
> > at org.tranql.connector.jdbc.ConnectionHandle.commit
> > (ConnectionHandle.java:115)
> > at
> > org.apache.geronimo.samples.daytrader.direct.TradeDirect.commit
> > (TradeDirect.java:2044)
> > at
> > org.apache.geronimo.samples.daytrader.direct.TradeDirect.resetTrade
> > (TradeDirect.java:1964)
> > at
> > org.apache.geronimo.samples.daytrader.ejb.TradeBean.resetTrade
> > (TradeBean.java:931)
> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > at sun.reflect.NativeMethodAccessorImpl.invoke
> > (NativeMethodAccessorImpl.java :64)
> > at sun.reflect.DelegatingMethodAccessorImpl.invoke
> > (DelegatingMethodAccessorImpl.java:43)
> > at java.lang.reflect.Method.invoke(Method.java:615)
> > at
> > org.apache.openejb.core.interceptor.ReflectionInvocationContext
> > $Invocation.invoke (ReflectionInvocationContext.java:146)
> > at
> > org.apache.openejb.core.interceptor.ReflectionInvocationContext.procee
> > d(ReflectionInvocationContext.java:129)
> > at
> > org.apache.openejb.core.interceptor.InterceptorStack.invoke
> > (InterceptorStack.java:67)
> > at
> > org.apache.openejb.core.stateless.StatelessContainer._invoke
> > (StatelessContainer.java:203)
> > at
> > org.apache.openejb.core.stateless.StatelessContainer.invoke
> > (StatelessContainer.java :165)
> > ...
> >
> > Anyone have any thoughts on this one?
> >
> > Chris
> >
> > --
> > "I say never be complete, I say stop being perfect, I say let...
> > lets evolve, let the chips fall where they may." - Tyler Durden
>
>
--
"I say never be complete, I say stop being perfect, I say let... lets
evolve, let the chips fall where they may." - Tyler Durden