Return-Path: Delivered-To: apmail-geronimo-dev-archive@www.apache.org Received: (qmail 51349 invoked from network); 1 Aug 2007 16:01:07 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 1 Aug 2007 16:01:07 -0000 Received: (qmail 22294 invoked by uid 500); 1 Aug 2007 16:01:04 -0000 Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org Received: (qmail 22155 invoked by uid 500); 1 Aug 2007 16:01:04 -0000 Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@geronimo.apache.org List-Id: Delivered-To: mailing list dev@geronimo.apache.org Received: (qmail 22144 invoked by uid 99); 1 Aug 2007 16:01:04 -0000 Received: from Unknown (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 01 Aug 2007 09:01:04 -0700 X-ASF-Spam-Status: No, hits=3.8 required=10.0 tests=HTML_MESSAGE,MIME_QP_LONG_LINE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [69.147.95.93] (HELO smtp130.plus.mail.sp1.yahoo.com) (69.147.95.93) by apache.org (qpsmtpd/0.29) with SMTP; Wed, 01 Aug 2007 16:00:51 +0000 Received: (qmail 61430 invoked from network); 1 Aug 2007 16:00:35 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-YMail-OSG:Mime-Version:In-Reply-To:References:Content-Type:Message-Id:From:Subject:Date:To:X-Mailer; b=a8a5elt3C8dFDO2Mr5qtw+V6uBTIK0TilHMh5QOVwix2PgeFXDU8nXUAhV3jOLNmt920kX606hBht8jRY6EiYdBpT3JiZ0ONn8eyA5vjN3QoY5ldch/c07cJlACOpHHH4XHkqdi04AAdo6i9WFh7xqnAgkoeRk8g+z1SnqFoqBg= ; Received: from unknown (HELO ?192.168.1.106?) (david_jencks@67.102.173.8 with plain) by smtp130.plus.mail.sp1.yahoo.com with SMTP; 1 Aug 2007 16:00:35 -0000 X-YMail-OSG: 2c_qfVgVM1kSIlQZjc2HgUg1Abh6X6T4u_.iXFls0oWv7Cf7YaWEwfu5MSP61grK89vFbzbr1w-- Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <421012bd0708010517g79a5fa98u2a8f39dbbd7ebbae@mail.gmail.com> References: <421012bd0707251957g1d87602ey58e03da88687274a@mail.gmail.com> <4F0B11B4-D718-4ACC-BC47-ABA0244E6CAE@visi.com> <421012bd0708010517g79a5fa98u2a8f39dbbd7ebbae@mail.gmail.com> Content-Type: multipart/alternative; boundary=Apple-Mail-2--629086536 Message-Id: From: David Jencks Subject: Re: Problems with method level container transactions in Geronimo 2.0 / OpenEJB Date: Wed, 1 Aug 2007 09:00:27 -0700 To: dev@geronimo.apache.org X-Mailer: Apple Mail (2.752.3) X-Virus-Checked: Checked by ClamAV on apache.org --Apple-Mail-2--629086536 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed 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 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... > > > > > > > > TradeEJB > > Remote > > resetTrade > > > > boolean > > > > > > ... > > NotSupported > > > > > > > > ... > > > > TradeEJB > > * > > > > ... > > Required > > > > 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@183e183e > > MC: org.tranql.connector.jdbc.ManagedXAConnection@29fa29fa from > > pool: > > > org.apache.geronimo.connector.outbound.SinglePoolConnectionInterceptor > > @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.procee > > 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 --Apple-Mail-2--629086536 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 The spec is clear about this = case anyway, on p 336 it says

Atransactionattributemaybespecifiedonamethodof thebeanclass = tooverridethetransaction=A0
attribute value explicitly or implicitly specified on the bean = class.=A0


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...
>
>=A0=A0=A0=A0=A0=A0=A0=A0 = <container-transaction>
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = <method>
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = <ejb-name>TradeEJB</ejb-name>
>=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 <method-intf>Remote</method-intf> =
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = <method-name>resetTrade</method-name>
>=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = <method-params>
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 = <method-param>boolean</method-param>
>=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 </method-params> =
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = </method>
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = ...
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = <trans-attribute>NotSupported</trans-attribute>
>=A0=A0=A0= =A0=A0=A0=A0=A0 </container-transaction>
>
>=A0=A0=A0=A0= =A0=A0=A0=A0 <container-transaction>
>=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 ...
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = <method>
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = <ejb-name>TradeEJB</ejb-name>
>=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 = <method-name>*</method-name>
>=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 </method>
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = ...
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = <trans-attribute>Required</trans-attribute>
>=A0=A0=A0=A0= =A0=A0=A0=A0 </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)).=A0=A0These 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.=A0=A0If 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=A0=A0[OpenEJB] invoking method resetTrade on = ejb/
> TradeEJB with identity null
> 22:11:51,437 = INFO=A0=A0[Transaction] TX Required: Started transaction
> = org.apache.geronimo.transaction.manager.TransactionImpl@240a240a
> = 22:11:51,437 TRACE [SinglePoolConnectionInterceptor] Supplying
> = pooled connection=A0=A0MCI:
> = org.apache.geronimo.connector.outbound.ManagedConnectionInfo@183e183e
&= gt; MC: org.tranql.connector.jdbc.ManagedXAConnection@29fa29fa = from
> pool:
> = org.apache.geronimo.connector.outbound.SinglePoolConnectionInterceptor =
> @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
>
>=A0=A0=A0=A0=A0=A0=A0=A0 = com.ibm.db2.jcc.b.SqlException: setAutoCommit(true) invalid
> = during global transaction
> com.ibm.db2.jcc.b.SqlException : = setAutoCommit(true) invalid during
> global = transaction
>=A0=A0=A0=A0=A0=A0=A0=A0 at = com.ibm.db2.jcc.b.p.setAutoCommit(p.java:1152)
>=A0=A0=A0=A0=A0=A0=A0= =A0 at com.ibm.db2.jcc.b.dc.setAutoCommit(dc.java:151)
>=A0=A0=A0=A0= =A0=A0=A0=A0 at
> = org.tranql.connector.jdbc.ManagedXAConnection.localTransactionCommit
&g= t; (ManagedXAConnection.java :104)
>=A0=A0=A0=A0=A0=A0=A0=A0 at = org.tranql.connector.AbstractManagedConnection
> = $LocalTransactionImpl.commit(AbstractManagedConnection.java = :192)
>=A0=A0=A0=A0=A0=A0=A0=A0 at = org.tranql.connector.jdbc.ConnectionHandle.commit
> = (ConnectionHandle.java:115)
>=A0=A0=A0=A0=A0=A0=A0=A0 at
> = org.apache.geronimo.samples.daytrader.direct.TradeDirect.commit
> = (TradeDirect.java :2044)
>=A0=A0=A0=A0=A0=A0=A0=A0 at
> = org.apache.geronimo.samples.daytrader.direct.TradeDirect.resetTrade
>= ; (TradeDirect.java:1964)
>=A0=A0=A0=A0=A0=A0=A0=A0 at
> = org.apache.geronimo.samples.daytrader.ejb.TradeBean.resetTrade
> = (TradeBean.java:931)
>=A0=A0=A0=A0=A0=A0=A0=A0 at = sun.reflect.NativeMethodAccessorImpl.invoke0(Native = Method)
>=A0=A0=A0=A0=A0=A0=A0=A0 at = sun.reflect.NativeMethodAccessorImpl.invoke
> = (NativeMethodAccessorImpl.java :64)
>=A0=A0=A0=A0=A0=A0=A0=A0 at = sun.reflect.DelegatingMethodAccessorImpl.invoke
> = (DelegatingMethodAccessorImpl.java:43)
>=A0=A0=A0=A0=A0=A0=A0=A0 = at java.lang.reflect.Method.invoke(Method.java:615)
>=A0=A0=A0=A0=A0= =A0=A0=A0 at
> = org.apache.openejb.core.interceptor.ReflectionInvocationContext
> = $Invocation.invoke = (ReflectionInvocationContext.java:146)
>=A0=A0=A0=A0=A0=A0=A0=A0 = at
> = org.apache.openejb.core.interceptor.ReflectionInvocationContext.procee
= > d(ReflectionInvocationContext.java:129)
>=A0=A0=A0=A0=A0=A0=A0=A0= at
> = org.apache.openejb.core.interceptor.InterceptorStack.invoke
> = (InterceptorStack.java:67)
>=A0=A0=A0=A0=A0=A0=A0=A0 at
> = org.apache.openejb.core.stateless.StatelessContainer._invoke
> = (StatelessContainer.java :203)
>=A0=A0=A0=A0=A0=A0=A0=A0 = at
> = org.apache.openejb.core.stateless.StatelessContainer.invoke
> = (StatelessContainer.java :165)
>=A0=A0=A0=A0=A0=A0=A0=A0 = ...
>
> 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

= --Apple-Mail-2--629086536--