geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: Problems with method level container transactions in Geronimo 2.0 / OpenEJB
Date Wed, 01 Aug 2007 16:03:39 GMT
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@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
>


Mime
View raw message