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 <[EMAIL PROTECTED]> 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 > > [EMAIL PROTECTED] > > 22:11:51,437 TRACE [SinglePoolConnectionInterceptor] Supplying > > pooled connection MCI: > > [EMAIL PROTECTED] > > MC: [EMAIL PROTECTED] from > > pool: > > org.apache.geronimo.connector.outbound.SinglePoolConnectionInterceptor > > @56525652 > > 22:11:51,437 TRACE [TransactionCachingInterceptor] supplying > > connection from pool null for managed connection > > [EMAIL PROTECTED] to tx > > caching interceptor > > [EMAIL PROTECTED] > > 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
