geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Blevins <david.blev...@visi.com>
Subject Re: Problems with method level container transactions in Geronimo 2.0 / OpenEJB
Date Wed, 01 Aug 2007 06:53:55 GMT
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


Mime
View raw message