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 Thu, 02 Aug 2007 06:23:23 GMT

On Aug 1, 2007, at 12:17 PM, David Blevins wrote:

> That's the info I was looking for.  I'll fix this.

Should be good now.

-David

>
> -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@183e18 
>>>> 3e
>>>> > MC: org.tranql.connector.jdbc.ManagedXAConnection@29fa29fa from
>>>> > pool:
>>>> >  
>>>> org.apache.geronimo.connector.outbound.SinglePoolConnectionIntercep 
>>>> tor
>>>> > @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.TransactionCachingIntercepto 
>>>> r@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.localTransactionCommi 
>>>> t
>>>> > (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.pro 
>>>> cee
>>>> > 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