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
