On Aug 1, 2007, at 2:44 PM, David Blevins wrote:

>
> On Aug 1, 2007, at 1:49 PM, Christopher Blythe wrote:
>
>> David...
>>
>> Do you have a JIRA for this yet?
>
>
> Added one here http://issues.apache.org/jira/browse/OPENEJB-623

Here click the this link to be notified of when it's fixed:

  http://issues.apache.org/jira/secure/ViewIssue.jspa? 
id=12375174&watch=true

-David

>
> -David
>
>>
>>
>>
>> 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
>
>