Hello! I've experienced the same problem on JBoss 3.0.4 through 3.0.6.
Before thoroughly searching the mailing lists and discovering this thread I had done some tracing of the TxCapsule and TxInterceptorCMT and added some notes to bug #575966. David, if your interested in an annotated log have a look at: http://unzane.com/sf-bug-575966.txt ...and related bug: http://sourceforge.net/tracker/index.php?func=detail&aid=575966&group_id=22866&atid=376685 I'll build the latest Branch_3_0 and give that a try. Jonathan.O'[EMAIL PROTECTED] writes: > David, > I'll see if I can CVSGrab the source tomorrow morning. Sadly we have a very > slow ISDN line here for 4 of us. I normally just wait for a release to pick up > the source in one go. > I'll let you know how it goes. > Ciao, > Jonathan O'Connor > Development Manager > XCOM Dublin > Phone: +353 1 872 3305 > Mobile: +353 86 824 0736 > > > David Jencks ~ ~ ~ ~ > ~[EMAIL PROTECTED]~ ~ ~ ~ ~ To: ~ ~ ~ > Sent by: ~[EMAIL PROTECTED] > [EMAIL PROTECTED] ~ ~ ~ ~ cc: ~ ~ ~ ~ > ~ ~ ~ ~ Subject: ~ ~ ~ ~Re: > 10.02.2003 17:04 [JBoss-user] Session Bean (Txn > Please respond to jboss-user Required) commit error not being > sent back to the client > > > Could you try 3.0.x from cvs? I ported (I think all of) the recent fixes > plus some new ones last night. ~Perhaps we are slowly converging on > reasonable behavior. > What should be happening now is that any exceptions during > synch.beforeCompletion, delist, prepare, or 1pc commit end up generating a > TransactionRolledback[Local]Exception. ~The entire chain of exceptions > (probably at least 4 deep) should implement org.jboss.util.NestedThrowable > so you should be able to traverse the chain of exceptions until you get the > original SQLException that Oracle threw. > You can also use or reimplement the ~JBossLocalXAExceptionFormatter to do > customized logging of the ~XAExceptions~ that wrap the original > SQLExceptions. ~To use it, just include an mbean descriptor for it in the > oracle-service.xml file. > Let me know how it works, I'd like feedback before porting this to 3.2 and > head. > david jencks > On 2003.02.10 11:28 Jonathan.O'[EMAIL PROTECTED] wrote: > ~ David, > ~ I finally got to try out 3.2.0RC1 and 3.0.6 today. As you probably know > ~ 3.0.6 still has problems with catching exceptions during the commit > ~ stage. > ~ 3.2.0RC1 has one of the problems fixed, but not the other. > ~ > ~ Here's what's fixed: > ~ Using Oracle 9i thi driver, we try writing a large blob to the database, > ~ using CMP. The write fails. In previous versions of JBoss 3, all > ~ subsequent uses of the DB connection failed. > ~ In 3.2.0RC1 this is fixed. Well done! > ~ > ~ However, the other problem, where I forget to set a non-nullable field in > ~ > ~ ejbCreate or ejbPostCreate (same effect), still does not return to the > ~ caller if the constraints are checked at commit time. > ~ As mentioned previously, this happens in ORACLE 9, if you set the field > ~ as > ~ DEFERRABLE INITIALLY DEFERRED. I have not found a way of replicating the > ~ problem using non-DB-specific SQL. > ~ > ~ Ciao, > ~ Jonathan O'Connor > ~ Development Manager > ~ XCOM Dublin > ~ Phone: +353 1 872 3305 > ~ Mobile: +353 86 824 0736 > ~ > ~ > ~ > ~ > ~ David Jencks ~[EMAIL PROTECTED]~ > ~ Sent by: [EMAIL PROTECTED] > ~ 24.01.2003 17:14 > ~ Please respond to jboss-user > ~ > ~ ~ > ~ ~ ~ ~ ~ To: ~ ~ [EMAIL PROTECTED] > ~ ~ ~ ~ ~ cc: > ~ ~ ~ ~ ~ Subject: ~ ~ ~ ~Re: [JBoss-user] Session Bean (Txn Required) > ~ commit error not being sent > ~ back to the client > ~ > ~ > ~ I thought this was fixed at least in 3.2 and head. ~Is there any chance > ~ you could try one of these? > ~ > ~ On Friday, January 24, 2003, at 12:11 PM, Jonathan.O'[EMAIL PROTECTED] > ~ wrote: > ~ > ~ ~ David, > ~ ~ Apologies for not giving version info. We use JBoss 3.0.5 running on > ~ ~ Windows and Linux. But it used to happen in 3.0.4 as well (I wrote to > ~ ~ the > ~ ~ list last November about it). > ~ ~ > ~ ~ The whole problem is that the database rollsback the transaction, and > ~ ~ the > ~ ~ JBoss server catches an XAException, but neither our entity/session > ~ ~ beans > ~ ~ nor our client application (JUnit) code gets to find out about this > ~ ~ rollback. Our client code continues on in its ignorant way, assuming > ~ ~ all > ~ ~ was well, and of course, trips up and falls over almost immediately > ~ ~ after > ~ ~ that. > ~ ~ > ~ ~ Sorry, I haven't read the spec, but TransactionRolledBackException or > ~ ~ TransactionRolledBackLocalException sound OK to me. It looks to me as > ~ ~ if fixing this will involve a good bit > ~ ~ of rework, to ensure the commit of the session bean transaction happens > ~ ~ while returning from the Session Bean method. As far as I can tell (or > ~ ~ should that be guess), the session bean method is long returned to the > ~ ~ client before the txn is actually committed. > ~ > ~ It is committed by the time the method returns. > ~ > ~ david > ~ ~ > ~ ~ Lastly, I'm off on holidays for a week, so if you don't see further > ~ ~ replies from me, I'm not being rude! > ~ ~ Ciao, > ~ ~ Jonathan O'Connor > ~ ~ Development Manager > ~ ~ XCOM Dublin > ~ ~ Phone: +353 1 872 3305 > ~ ~ Mobile: +353 86 824 0736 > ~ ~ > ~ ~ > ~ ~ > ~ ~ > ~ ~ David Jencks ~[EMAIL PROTECTED]~ > ~ ~ Sent by: [EMAIL PROTECTED] > ~ ~ 24.01.2003 15:01 > ~ ~ Please respond to jboss-user > ~ ~ > ~ ~ > ~ ~ ~ ~ ~ ~ To: ~ ~ [EMAIL PROTECTED] > ~ ~ ~ ~ ~ ~ cc: > ~ ~ ~ ~ ~ ~ Subject: ~ ~ ~ ~Re: [JBoss-user] Session Bean (Txn Required) > ~ ~ commit error not being sent > ~ ~ back to the client > ~ ~ > ~ ~ > ~ ~ Which jboss? > ~ ~ What does happen? > ~ ~ Do you know the spec required behavior? ~I think it should be > ~ ~ TransactionRolledBackException or TransactionRolledBackLocalException, > ~ ~ but I haven't looked in the spec recently. > ~ ~ > ~ ~ david jencks > ~ ~ > ~ ~ On Friday, January 24, 2003, at 07:22 AM, Jonathan.O'[EMAIL PROTECTED] > ~ ~ wrote: > ~ ~ > ~ ~~ Yesterday, we got bitten by the same bug that bit us last November. > ~ ~~ Here's > ~ ~~ what happens: > ~ ~~ 1. A client app (JUnit tester) calls a method in a session bean (via > ~ ~~ remote interface). The method is marked as Transaction required. > ~ ~~ 1a. A transaction is started automatically by JBoss. > ~ ~~ 2. The session bean method creates an entity bean. Because we use > ~ ~~ Oracle, > ~ ~~ we mark a foreign key field as NOT NULL DEFERRABLE INITIALLY DEFERRED. > ~ ~~ This means that the NOT NULL constraint is only checked at commit > ~ ~~ time, > ~ ~~ rather than at insert or update time. > ~ ~~ 3. The ejbCreate and ejbPostCreate of our entity bean don't call > ~ ~~ setFKField(), so this field remains NULL. > ~ ~~ 4. The code returns from the session bean method. > ~ ~~ 5. JBoss sees that the code has exited the session bean method marked > ~ ~~ as > ~ ~~ Txn Required, and tries to commit the Txn. > ~ ~~ 6. Oracle now kicks in, and checks all the deferred constraints. > ~ ~~ Naturally > ~ ~~ one of them fails, so Oracle returns an exception saying the > ~ ~~ transaction > ~ ~~ has failed. > ~ ~~ > ~ ~~ Now for the bug: > ~ ~~ ~ ~ ~ ~ There is no place in my code where I can catch this > ~ ~~ XAException. > ~ ~~ Expected Result: > ~ ~~ ~ ~ ~ ~ The XAException should be turned into some sort of > ~ ~~ EJBException > ~ ~~ and returned to the caller of the session bean method. > ~ ~~ > ~ ~~ I'd be happy to provide a small test case for this, but it would use > ~ ~~ Oracle. I guess it is possible to get this bug using other databases, > ~ ~~ but > ~ ~~ I think the SQL script would be DB specific. > ~ ~~ > ~ ~~ 2003-01-24 11:44:08,275 WARN ~[org.jboss.tm.TxCapsule] XAException: > ~ ~~ tx=XidImpl [FormatId=257, GlobalId=XCOM-IRL-JONATHAN//8, BranchQual=] > ~ ~~ errorCode=XA_UNKNOWN(0) > ~ ~~ javax.transaction.xa.XAException: could not commit local > ~ ~~ txjavax.resource.ResourceException: SQLException > ~ ~~ ~ ~ ~ ~ at > ~ ~~ org.jboss.resource.connectionmanager.LocalTxConnectionManager$LocalCon > ~ > ~ ~~ n > ~ ~~ ectionEventListener.commit(LocalTxConnectionManager.java:567) > ~ ~~ ~ ~ ~ ~ at org.jboss.tm.TxCapsule.commitResources(TxCapsule.java:1714) > ~ ~~ ~ ~ ~ ~ at org.jboss.tm.TxCapsule.commit(TxCapsule.java:393) > ~ ~~ ~ ~ ~ ~ at > ~ ~~ org.jboss.tm.TransactionImpl.commit(TransactionImpl.java:73) > ~ ~~ ~ ~ ~ ~ at > ~ ~~ org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxIntercept > ~ > ~ ~~ o > ~ ~~ rCMT.java:251) > ~ ~~ ~ ~ ~ ~ at > ~ ~~ org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:92 > ~ > ~ ~~ ) > ~ ~~ ~ ~ ~ ~ at > ~ ~~ org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.j > ~ > ~ ~~ a > ~ ~~ va:130) > ~ ~~ ~ ~ ~ ~ at > ~ ~~ org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:204) > ~ ~~ ~ ~ ~ ~ at > ~ ~~ org.jboss.ejb.StatelessSessionContainer.invoke(StatelessSessionContain > ~ > ~ ~~ e > ~ ~~ r.java:313) > ~ ~~ ~ ~ ~ ~ at org.jboss.ejb.Container.invoke(Container.java:712) > ~ ~~ ~ ~ ~ ~ at > ~ ~~ org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517) > ~ ~~ ~ ~ ~ ~ at > ~ ~~ org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:3 > ~ > ~ ~~ 8 > ~ ~~ 2) > ~ ~~ ~ ~ ~ ~ at sun.reflect.GeneratedMethodAccessor35.invoke(Unknown > ~ ~~ Source) > ~ ~~ ~ ~ ~ ~ at > ~ ~~ sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccess > ~ > ~ ~~ o > ~ ~~ rImpl.java:25) > ~ ~~ ~ ~ ~ ~ at java.lang.reflect.Method.invoke(Method.java:324) > ~ ~~ ~ ~ ~ ~ at > ~ ~~ sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:261) > ~ ~~ ~ ~ ~ ~ at sun.rmi.transport.Transport$1.run(Transport.java:148) > ~ ~~ ~ ~ ~ ~ at java.security.AccessController.doPrivileged(Native Method) > ~ ~~ ~ ~ ~ ~ at sun.rmi.transport.Transport.serviceCall(Transport.java:144) > ~ ~~ ~ ~ ~ ~ at > ~ ~~ sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:46 > ~ > ~ ~~ 0 > ~ ~~ ) > ~ ~~ ~ ~ ~ ~ at > ~ ~~ sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport. > ~ > ~ ~~ j > ~ ~~ ava:701) > ~ ~~ ~ ~ ~ ~ at java.lang.Thread.run(Thread.java:536) > ~ ~~ Ciao, > ~ ~~ Jonathan O'Connor > ~ ~~ Development Manager > ~ ~~ XCOM Dublin > ~ ~~ Phone: +353 1 872 3305 > ~ ~~ Mobile: +353 86 824 0736 > ~ ~~ > ~ ~~ > ~ ~~ ------------------------------------------------------- > ~ ~~ This SF.NET email is sponsored by: > ~ ~~ SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > ~ ~~ http://www.vasoftware.com > ~ ~~ _______________________________________________ > ~ ~~ JBoss-user mailing list > ~ ~~ [EMAIL PROTECTED] > ~ ~~ https://lists.sourceforge.net/lists/listinfo/jboss-user > ~ ~~ > ~ ~ > ~ ~ > ~ ~ > ~ ~ ------------------------------------------------------- > ~ ~ This SF.NET email is sponsored by: > ~ ~ SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > ~ ~ http://www.vasoftware.com > ~ ~ _______________________________________________ > ~ ~ JBoss-user mailing list > ~ ~ [EMAIL PROTECTED] > ~ ~ https://lists.sourceforge.net/lists/listinfo/jboss-user > ~ ~ > ~ ~ > ~ ~ > ~ ~ > ~ ~ > ~ ~ ------------------------------------------------------- > ~ ~ This SF.NET email is sponsored by: > ~ ~ SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > ~ ~ http://www.vasoftware.com > ~ ~ _______________________________________________ > ~ ~ JBoss-user mailing list > ~ ~ [EMAIL PROTECTED] > ~ ~ https://lists.sourceforge.net/lists/listinfo/jboss-user > ~ ~ > ~ > ~ > ~ > ~ ------------------------------------------------------- > ~ This SF.NET email is sponsored by: > ~ SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > ~ http://www.vasoftware.com > ~ _______________________________________________ > ~ JBoss-user mailing list > ~ [EMAIL PROTECTED] > ~ https://lists.sourceforge.net/lists/listinfo/jboss-user > ~ > ~ > ~ > ~ > ~ ~br~~font size=2 face=~sans-serif~~David,~/font~ > ~ ~br~~font size=2 face=~sans-serif~~I finally got to try out 3.2.0RC1 and > ~ 3.0.6 today. As you probably know 3.0.6 still has problems with catching > ~ exceptions during the commit stage.~/font~ > ~ ~br~~font size=2 face=~sans-serif~~3.2.0RC1 has one of the problems > ~ fixed, but not the other.~/font~ > ~ ~br~ > ~ ~br~~font size=2 face=~sans-serif~~Here's what's fixed:~/font~ > ~ ~br~~font size=2 face=~sans-serif~~Using Oracle 9i thi driver, we try > ~ writing a large blob to the database, using CMP. The write fails. In > ~ previous versions of JBoss 3, all subsequent uses of the DB connection > ~ failed.~/font~ > ~ ~br~~font size=2 face=~sans-serif~~In 3.2.0RC1 this is fixed. Well > ~ done!~/font~ > ~ ~br~ > ~ ~br~~font size=2 face=~sans-serif~~However, the other problem, where I > ~ forget to set a non-nullable field in ejbCreate or ejbPostCreate (same > ~ effect), still does not return to the caller if the constraints are > ~ checked at commit time.~/font~ > ~ ~br~~font size=2 face=~sans-serif~~As mentioned previously, this happens > ~ in ORACLE 9, if you set the field as DEFERRABLE INITIALLY DEFERRED. I > ~ have not found a way of replicating the problem using non-DB-specific > ~ SQL.~/font~ > ~ ~br~ > ~ ~br~~font size=2 face=~sans-serif~~Ciao,~br~ > ~ Jonathan O'Connor~br~ > ~ Development Manager~br~ > ~ XCOM Dublin~br~ > ~ Phone: +353 1 872 3305~br~ > ~ Mobile: +353 86 824 0736~/font~ > ~ ~br~ > ~ ~br~ > ~ ~br~ > ~ ~table width=100%~ > ~ ~tr valign=top~ > ~ ~td~ > ~ ~td~~font size=1 face=~sans-serif~~~b~David Jencks > ~ ~lt;[EMAIL PROTECTED]~gt;~/b~~/font~ > ~ ~br~~font size=1 face=~sans-serif~~Sent by: > ~ [EMAIL PROTECTED]~/font~ > ~ ~p~~font size=1 face=~sans-serif~~24.01.2003 17:14~/font~ > ~ ~br~~font size=1 face=~sans-serif~~Please respond to jboss-user~/font~ > ~ ~br~ > ~ ~td~~font size=1 face=~Arial~~~nbsp; ~nbsp; ~nbsp; ~nbsp; ~/font~ > ~ ~br~~font size=1 face=~sans-serif~~~nbsp; ~nbsp; ~nbsp; ~nbsp; To: ~nbsp; > ~ ~nbsp; ~nbsp; ~nbsp;[EMAIL PROTECTED]~/font~ > ~ ~br~~font size=1 face=~sans-serif~~~nbsp; ~nbsp; ~nbsp; ~nbsp; cc: ~nbsp; > ~ ~nbsp; ~nbsp; ~nbsp;~/font~ > ~ ~br~~font size=1 face=~sans-serif~~~nbsp; ~nbsp; ~nbsp; ~nbsp; Subject: > ~ ~nbsp; ~nbsp; ~nbsp; ~nbsp;Re: [JBoss-user] Session Bean (Txn Required) > ~ commit error not being sent back to the client~/font~~/table~ > ~ ~br~ > ~ ~br~ > ~ ~br~~font size=2 face=~Courier New~~I thought this was fixed at least in > ~ 3.2 and head. ~nbsp;Is there any chance ~nbsp;~br~ > ~ you could try one of these?~br~ > ~ ~br~ > ~ On Friday, January 24, 2003, at 12:11 PM, Jonathan.O'[EMAIL PROTECTED] > ~ ~nbsp;~br~ > ~ wrote:~br~ > ~ ~br~ > ~ ~gt; David,~br~ > ~ ~gt; Apologies for not giving version info. We use JBoss 3.0.5 running > ~ on~br~ > ~ ~gt; Windows and Linux. But it used to happen in 3.0.4 as well (I wrote > ~ to ~nbsp;~br~ > ~ ~gt; the~br~ > ~ ~gt; list last November about it).~br~ > ~ ~gt;~br~ > ~ ~gt; The whole problem is that the database rollsback the transaction, > ~ and ~nbsp;~br~ > ~ ~gt; the~br~ > ~ ~gt; JBoss server catches an XAException, but neither our entity/session > ~ ~nbsp;~br~ > ~ ~gt; beans~br~ > ~ ~gt; nor our client application (JUnit) code gets to find out about > ~ this~br~ > ~ ~gt; rollback. Our client code continues on in its ignorant way, assuming > ~ ~nbsp;~br~ > ~ ~gt; all~br~ > ~ ~gt; was well, and of course, trips up and falls over almost immediately > ~ ~nbsp;~br~ > ~ ~gt; after~br~ > ~ ~gt; that.~br~ > ~ ~gt;~br~ > ~ ~gt; Sorry, I haven't read the spec, but TransactionRolledBackException > ~ or ~nbsp;~br~ > ~ ~gt; TransactionRolledBackLocalException sound OK to me. It looks to me > ~ as ~nbsp;~br~ > ~ ~gt; if fixing this will involve a good bit~br~ > ~ ~gt; of rework, to ensure the commit of the session bean transaction > ~ happens~br~ > ~ ~gt; while returning from the Session Bean method. As far as I can tell > ~ (or~br~ > ~ ~gt; should that be guess), the session bean method is long returned to > ~ the~br~ > ~ ~gt; client before the txn is actually committed.~br~ > ~ ~br~ > ~ It is committed by the time the method returns.~br~ > ~ ~br~ > ~ david~br~ > ~ ~gt;~br~ > ~ ~gt; Lastly, I'm off on holidays for a week, so if you don't see > ~ further~br~ > ~ ~gt; replies from me, I'm not being rude!~br~ > ~ ~gt; Ciao,~br~ > ~ ~gt; Jonathan O'Connor~br~ > ~ ~gt; Development Manager~br~ > ~ ~gt; XCOM Dublin~br~ > ~ ~gt; Phone: +353 1 872 3305~br~ > ~ ~gt; Mobile: +353 86 824 0736~br~ > ~ ~gt;~br~ > ~ ~gt;~br~ > ~ ~gt;~br~ > ~ ~gt;~br~ > ~ ~gt; David Jencks ~lt;[EMAIL PROTECTED]~gt;~br~ > ~ ~gt; Sent by: [EMAIL PROTECTED]~br~ > ~ ~gt; 24.01.2003 15:01~br~ > ~ ~gt; Please respond to jboss-user~br~ > ~ ~gt;~br~ > ~ ~gt;~br~ > ~ ~gt; ~nbsp; ~nbsp; ~nbsp; ~nbsp; To: ~nbsp; ~nbsp; > ~ [EMAIL PROTECTED]~br~ > ~ ~gt; ~nbsp; ~nbsp; ~nbsp; ~nbsp; cc:~br~ > ~ ~gt; ~nbsp; ~nbsp; ~nbsp; ~nbsp; Subject: ~nbsp; ~nbsp; ~nbsp; ~nbsp;Re: > ~ [JBoss-user] Session Bean (Txn Required) ~nbsp;~br~ > ~ ~gt; commit error not being sent~br~ > ~ ~gt; back to the client~br~ > ~ ~gt;~br~ > ~ ~gt;~br~ > ~ ~gt; Which jboss?~br~ > ~ ~gt; What does happen?~br~ > ~ ~gt; Do you know the spec required behavior? ~nbsp;I think it should > ~ be~br~ > ~ ~gt; TransactionRolledBackException or > ~ TransactionRolledBackLocalException,~br~ > ~ ~gt; but I haven't looked in the spec recently.~br~ > ~ ~gt;~br~ > ~ ~gt; david jencks~br~ > ~ ~gt;~br~ > ~ ~gt; On Friday, January 24, 2003, at 07:22 AM, > ~ Jonathan.O'[EMAIL PROTECTED]~br~ > ~ ~gt; wrote:~br~ > ~ ~gt;~br~ > ~ ~gt;~gt; Yesterday, we got bitten by the same bug that bit us last > ~ November.~br~ > ~ ~gt;~gt; Here's~br~ > ~ ~gt;~gt; what happens:~br~ > ~ ~gt;~gt; 1. A client app (JUnit tester) calls a method in a session bean > ~ (via~br~ > ~ ~gt;~gt; remote interface). The method is marked as Transaction > ~ required.~br~ > ~ ~gt;~gt; 1a. A transaction is started automatically by JBoss.~br~ > ~ ~gt;~gt; 2. The session bean method creates an entity bean. Because we > ~ use~br~ > ~ ~gt;~gt; Oracle,~br~ > ~ ~gt;~gt; we mark a foreign key field as NOT NULL DEFERRABLE INITIALLY > ~ DEFERRED.~br~ > ~ ~gt;~gt; This means that the NOT NULL constraint is only checked at > ~ commit ~nbsp;~br~ > ~ ~gt;~gt; time,~br~ > ~ ~gt;~gt; rather than at insert or update time.~br~ > ~ ~gt;~gt; 3. The ejbCreate and ejbPostCreate of our entity bean don't > ~ call~br~ > ~ ~gt;~gt; setFKField(), so this field remains NULL.~br~ > ~ ~gt;~gt; 4. The code returns from the session bean method.~br~ > ~ ~gt;~gt; 5. JBoss sees that the code has exited the session bean method > ~ marked~br~ > ~ ~gt;~gt; as~br~ > ~ ~gt;~gt; Txn Required, and tries to commit the Txn.~br~ > ~ ~gt;~gt; 6. Oracle now kicks in, and checks all the deferred > ~ constraints.~br~ > ~ ~gt;~gt; Naturally~br~ > ~ ~gt;~gt; one of them fails, so Oracle returns an exception saying the~br~ > ~ ~gt;~gt; transaction~br~ > ~ ~gt;~gt; has failed.~br~ > ~ ~gt;~gt;~br~ > ~ ~gt;~gt; Now for the bug:~br~ > ~ ~gt;~gt; ~nbsp; ~nbsp; ~nbsp; ~nbsp; There is no place in my code where I > ~ can catch this~br~ > ~ ~gt;~gt; XAException.~br~ > ~ ~gt;~gt; Expected Result:~br~ > ~ ~gt;~gt; ~nbsp; ~nbsp; ~nbsp; ~nbsp; The XAException should be turned > ~ into some sort of ~nbsp;~br~ > ~ ~gt;~gt; EJBException~br~ > ~ ~gt;~gt; and returned to the caller of the session bean method.~br~ > ~ ~gt;~gt;~br~ > ~ ~gt;~gt; I'd be happy to provide a small test case for this, but it would > ~ use~br~ > ~ ~gt;~gt; Oracle. I guess it is possible to get this bug using other > ~ databases,~br~ > ~ ~gt;~gt; but~br~ > ~ ~gt;~gt; I think the SQL script would be DB specific.~br~ > ~ ~gt;~gt;~br~ > ~ ~gt;~gt; 2003-01-24 11:44:08,275 WARN ~nbsp;[org.jboss.tm.TxCapsule] > ~ XAException:~br~ > ~ ~gt;~gt; tx=XidImpl [FormatId=257, GlobalId=XCOM-IRL-JONATHAN//8, > ~ BranchQual=]~br~ > ~ ~gt;~gt; errorCode=XA_UNKNOWN(0)~br~ > ~ ~gt;~gt; javax.transaction.xa.XAException: could not commit local~br~ > ~ ~gt;~gt; txjavax.resource.ResourceException: SQLException~br~ > ~ ~gt;~gt; ~nbsp; ~nbsp; ~nbsp; ~nbsp; at~br~ > ~ ~gt;~gt; > org.jboss.resource.connectionmanager.LocalTxConnectionManager$LocalCon > ~ ~br~ > ~ ~gt;~gt; n~br~ > ~ ~gt;~gt; ectionEventListener.commit(LocalTxConnectionManager.java:567)~br~ > ~ ~gt;~gt; ~nbsp; ~nbsp; ~nbsp; ~nbsp; at > ~ org.jboss.tm.TxCapsule.commitResources(TxCapsule.java:1714)~br~ > ~ ~gt;~gt; ~nbsp; ~nbsp; ~nbsp; ~nbsp; at > ~ org.jboss.tm.TxCapsule.commit(TxCapsule.java:393)~br~ > ~ ~gt;~gt; ~nbsp; ~nbsp; ~nbsp; ~nbsp; at ~nbsp;~br~ > ~ ~gt;~gt; org.jboss.tm.TransactionImpl.commit(TransactionImpl.java:73)~br~ > ~ ~gt;~gt; ~nbsp; ~nbsp; ~nbsp; ~nbsp; at~br~ > ~ ~gt;~gt; > org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxIntercept > ~ ~br~ > ~ ~gt;~gt; o~br~ > ~ ~gt;~gt; rCMT.java:251)~br~ > ~ ~gt;~gt; ~nbsp; ~nbsp; ~nbsp; ~nbsp; at~br~ > ~ ~gt;~gt; > org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:92 > ~ ~br~ > ~ ~gt;~gt; )~br~ > ~ ~gt;~gt; ~nbsp; ~nbsp; ~nbsp; ~nbsp; at~br~ > ~ ~gt;~gt; > org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.j > ~ ~br~ > ~ ~gt;~gt; a~br~ > ~ ~gt;~gt; va:130)~br~ > ~ ~gt;~gt; ~nbsp; ~nbsp; ~nbsp; ~nbsp; at~br~ > ~ ~gt;~gt; > org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:204)~br~ > ~ ~gt;~gt; ~nbsp; ~nbsp; ~nbsp; ~nbsp; at~br~ > ~ ~gt;~gt; > org.jboss.ejb.StatelessSessionContainer.invoke(StatelessSessionContain > ~ ~br~ > ~ ~gt;~gt; e~br~ > ~ ~gt;~gt; r.java:313)~br~ > ~ ~gt;~gt; ~nbsp; ~nbsp; ~nbsp; ~nbsp; at > ~ org.jboss.ejb.Container.invoke(Container.java:712)~br~ > ~ ~gt;~gt; ~nbsp; ~nbsp; ~nbsp; ~nbsp; at~br~ > ~ ~gt;~gt; > org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517)~br~ > ~ ~gt;~gt; ~nbsp; ~nbsp; ~nbsp; ~nbsp; at~br~ > ~ ~gt;~gt; > org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:3 > ~ ~br~ > ~ ~gt;~gt; 8~br~ > ~ ~gt;~gt; 2)~br~ > ~ ~gt;~gt; ~nbsp; ~nbsp; ~nbsp; ~nbsp; at > ~ sun.reflect.GeneratedMethodAccessor35.invoke(Unknown ~nbsp;~br~ > ~ ~gt;~gt; Source)~br~ > ~ ~gt;~gt; ~nbsp; ~nbsp; ~nbsp; ~nbsp; at~br~ > ~ ~gt;~gt; > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccess > ~ ~br~ > ~ ~gt;~gt; o~br~ > ~ ~gt;~gt; rImpl.java:25)~br~ > ~ ~gt;~gt; ~nbsp; ~nbsp; ~nbsp; ~nbsp; at > ~ java.lang.reflect.Method.invoke(Method.java:324)~br~ > ~ ~gt;~gt; ~nbsp; ~nbsp; ~nbsp; ~nbsp; at~/font~ > ~ ~br~~font size=2 face=~Courier New~~~gt;~gt; > ~ sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:261)~br~ > ~ ~gt;~gt; ~nbsp; ~nbsp; ~nbsp; ~nbsp; at > ~ sun.rmi.transport.Transport$1.run(Transport.java:148)~br~ > ~ ~gt;~gt; ~nbsp; ~nbsp; ~nbsp; ~nbsp; at > ~ java.security.AccessController.doPrivileged(Native Method)~br~ > ~ ~gt;~gt; ~nbsp; ~nbsp; ~nbsp; ~nbsp; at > ~ sun.rmi.transport.Transport.serviceCall(Transport.java:144)~br~ > ~ ~gt;~gt; ~nbsp; ~nbsp; ~nbsp; ~nbsp; at~br~ > ~ ~gt;~gt; > sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:46 > ~ ~br~ > ~ ~gt;~gt; 0~br~ > ~ ~gt;~gt; )~br~ > ~ ~gt;~gt; ~nbsp; ~nbsp; ~nbsp; ~nbsp; at~br~ > ~ ~gt;~gt; > sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport. > ~ ~br~ > ~ ~gt;~gt; j~br~ > ~ ~gt;~gt; ava:701)~br~ > ~ ~gt;~gt; ~nbsp; ~nbsp; ~nbsp; ~nbsp; at > ~ java.lang.Thread.run(Thread.java:536)~br~ > ~ ~gt;~gt; Ciao,~br~ > ~ ~gt;~gt; Jonathan O'Connor~br~ > ~ ~gt;~gt; Development Manager~br~ > ~ ~gt;~gt; XCOM Dublin~br~ > ~ ~gt;~gt; Phone: +353 1 872 3305~br~ > ~ ~gt;~gt; Mobile: +353 86 824 0736~br~ > ~ ~gt;~gt;~br~ > ~ ~gt;~gt;~br~ > ~ ~gt;~gt; -------------------------------------------------------~br~ > ~ ~gt;~gt; This SF.NET email is sponsored by:~br~ > ~ ~gt;~gt; SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 > ~ See!~br~ > ~ ~gt;~gt; http://www.vasoftware.com~br~ > ~ ~gt;~gt; _______________________________________________~br~ > ~ ~gt;~gt; JBoss-user mailing list~br~ > ~ ~gt;~gt; [EMAIL PROTECTED]~br~ > ~ ~gt;~gt; https://lists.sourceforge.net/lists/listinfo/jboss-user~br~ > ~ ~gt;~gt;~br~ > ~ ~gt;~br~ > ~ ~gt;~br~ > ~ ~gt;~br~ > ~ ~gt; -------------------------------------------------------~br~ > ~ ~gt; This SF.NET email is sponsored by:~br~ > ~ ~gt; SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 > ~ See!~br~ > ~ ~gt; http://www.vasoftware.com~br~ > ~ ~gt; _______________________________________________~br~ > ~ ~gt; JBoss-user mailing list~br~ > ~ ~gt; [EMAIL PROTECTED]~br~ > ~ ~gt; https://lists.sourceforge.net/lists/listinfo/jboss-user~br~ > ~ ~gt;~br~ > ~ ~gt;~br~ > ~ ~gt;~br~ > ~ ~gt;~br~ > ~ ~gt;~br~ > ~ ~gt; -------------------------------------------------------~br~ > ~ ~gt; This SF.NET email is sponsored by:~br~ > ~ ~gt; SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 > ~ See!~br~ > ~ ~gt; http://www.vasoftware.com~br~ > ~ ~gt; _______________________________________________~br~ > ~ ~gt; JBoss-user mailing list~br~ > ~ ~gt; [EMAIL PROTECTED]~br~ > ~ ~gt; https://lists.sourceforge.net/lists/listinfo/jboss-user~br~ > ~ ~gt;~br~ > ~ ~br~ > ~ ~br~ > ~ ~br~ > ~ -------------------------------------------------------~br~ > ~ This SF.NET email is sponsored by:~br~ > ~ SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!~br~ > ~ http://www.vasoftware.com~br~ > ~ _______________________________________________~br~ > ~ JBoss-user mailing list~br~ > ~ [EMAIL PROTECTED]~br~ > ~ https://lists.sourceforge.net/lists/listinfo/jboss-user~br~ > ~ ~/font~ > ~ ~br~ > ~ ~br~ > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > _______________________________________________ > JBoss-user mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-user > -- Gerald Turner Email: [EMAIL PROTECTED] Phone: (503) 788-1720 GPG: 0xFA8CD6D5 21D9 B2E8 7FE7 F19E 5F7D 4D0C 3FA0 810F FA8C D6D5 ------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
