David... Do you have a JIRA for this yet?
On 8/1/07, David Blevins <[EMAIL PROTECTED]> 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 <[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] > >>> e > >>> > MC: [EMAIL PROTECTED] from > >>> > pool: > >>> > > >>> org.apache.geronimo.connector.outbound.SinglePoolConnectionIntercept > >>> or > >>> > @56525652 > >>> > 22:11:51,437 TRACE [TransactionCachingInterceptor] supplying > >>> > connection from pool null for managed connection > >>> > [EMAIL PROTECTED] 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
