geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher Blythe" <cjblyth...@gmail.com>
Subject Re: Problems with method level container transactions in Geronimo 2.0 / OpenEJB
Date Wed, 01 Aug 2007 20:49:55 GMT
David...

Do you have a JIRA for this yet?



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

Mime
View raw message