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 > <[EMAIL PROTECTED]></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"> </font> > <br><font size=1 face="sans-serif"> To: > [EMAIL PROTECTED]</font> > <br><font size=1 face="sans-serif"> cc: > </font> > <br><font size=1 face="sans-serif"> Subject: > 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. Is there any chance <br> > you could try one of these?<br> > <br> > On Friday, January 24, 2003, at 12:11 PM, Jonathan.O'[EMAIL PROTECTED] > <br> > wrote:<br> > <br> > > David,<br> > > Apologies for not giving version info. We use JBoss 3.0.5 running > on<br> > > Windows and Linux. But it used to happen in 3.0.4 as well (I wrote > to <br> > > the<br> > > list last November about it).<br> > ><br> > > The whole problem is that the database rollsback the transaction, > and <br> > > the<br> > > JBoss server catches an XAException, but neither our entity/session > <br> > > beans<br> > > nor our client application (JUnit) code gets to find out about > this<br> > > rollback. Our client code continues on in its ignorant way, assuming > <br> > > all<br> > > was well, and of course, trips up and falls over almost immediately > <br> > > after<br> > > that.<br> > ><br> > > Sorry, I haven't read the spec, but TransactionRolledBackException > or <br> > > TransactionRolledBackLocalException sound OK to me. It looks to me > as <br> > > if fixing this will involve a good bit<br> > > of rework, to ensure the commit of the session bean transaction > happens<br> > > while returning from the Session Bean method. As far as I can tell > (or<br> > > should that be guess), the session bean method is long returned to > the<br> > > client before the txn is actually committed.<br> > <br> > It is committed by the time the method returns.<br> > <br> > david<br> > ><br> > > Lastly, I'm off on holidays for a week, so if you don't see > further<br> > > replies from me, I'm not being rude!<br> > > Ciao,<br> > > Jonathan O'Connor<br> > > Development Manager<br> > > XCOM Dublin<br> > > Phone: +353 1 872 3305<br> > > Mobile: +353 86 824 0736<br> > ><br> > ><br> > ><br> > ><br> > > David Jencks <[EMAIL PROTECTED]><br> > > Sent by: [EMAIL PROTECTED]<br> > > 24.01.2003 15:01<br> > > Please respond to jboss-user<br> > ><br> > ><br> > > To: > [EMAIL PROTECTED]<br> > > cc:<br> > > Subject: Re: > [JBoss-user] Session Bean (Txn Required) <br> > > commit error not being sent<br> > > back to the client<br> > ><br> > ><br> > > Which jboss?<br> > > What does happen?<br> > > Do you know the spec required behavior? I think it should > be<br> > > TransactionRolledBackException or > TransactionRolledBackLocalException,<br> > > but I haven't looked in the spec recently.<br> > ><br> > > david jencks<br> > ><br> > > On Friday, January 24, 2003, at 07:22 AM, > Jonathan.O'[EMAIL PROTECTED]<br> > > wrote:<br> > ><br> > >> Yesterday, we got bitten by the same bug that bit us last > November.<br> > >> Here's<br> > >> what happens:<br> > >> 1. A client app (JUnit tester) calls a method in a session bean > (via<br> > >> remote interface). The method is marked as Transaction > required.<br> > >> 1a. A transaction is started automatically by JBoss.<br> > >> 2. The session bean method creates an entity bean. Because we > use<br> > >> Oracle,<br> > >> we mark a foreign key field as NOT NULL DEFERRABLE INITIALLY > DEFERRED.<br> > >> This means that the NOT NULL constraint is only checked at > commit <br> > >> time,<br> > >> rather than at insert or update time.<br> > >> 3. The ejbCreate and ejbPostCreate of our entity bean don't > call<br> > >> setFKField(), so this field remains NULL.<br> > >> 4. The code returns from the session bean method.<br> > >> 5. JBoss sees that the code has exited the session bean method > marked<br> > >> as<br> > >> Txn Required, and tries to commit the Txn.<br> > >> 6. Oracle now kicks in, and checks all the deferred > constraints.<br> > >> Naturally<br> > >> one of them fails, so Oracle returns an exception saying the<br> > >> transaction<br> > >> has failed.<br> > >><br> > >> Now for the bug:<br> > >> There is no place in my code where I > can catch this<br> > >> XAException.<br> > >> Expected Result:<br> > >> The XAException should be turned > into some sort of <br> > >> EJBException<br> > >> and returned to the caller of the session bean method.<br> > >><br> > >> I'd be happy to provide a small test case for this, but it would > use<br> > >> Oracle. I guess it is possible to get this bug using other > databases,<br> > >> but<br> > >> I think the SQL script would be DB specific.<br> > >><br> > >> 2003-01-24 11:44:08,275 WARN [org.jboss.tm.TxCapsule] > XAException:<br> > >> tx=XidImpl [FormatId=257, GlobalId=XCOM-IRL-JONATHAN//8, > BranchQual=]<br> > >> errorCode=XA_UNKNOWN(0)<br> > >> javax.transaction.xa.XAException: could not commit local<br> > >> txjavax.resource.ResourceException: SQLException<br> > >> at<br> > >> org.jboss.resource.connectionmanager.LocalTxConnectionManager$LocalCon > <br> > >> n<br> > >> ectionEventListener.commit(LocalTxConnectionManager.java:567)<br> > >> at > org.jboss.tm.TxCapsule.commitResources(TxCapsule.java:1714)<br> > >> at > org.jboss.tm.TxCapsule.commit(TxCapsule.java:393)<br> > >> at <br> > >> org.jboss.tm.TransactionImpl.commit(TransactionImpl.java:73)<br> > >> at<br> > >> org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxIntercept > <br> > >> o<br> > >> rCMT.java:251)<br> > >> at<br> > >> org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:92 > <br> > >> )<br> > >> at<br> > >> org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.j > <br> > >> a<br> > >> va:130)<br> > >> at<br> > >> org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:204)<br> > >> at<br> > >> org.jboss.ejb.StatelessSessionContainer.invoke(StatelessSessionContain > <br> > >> e<br> > >> r.java:313)<br> > >> at > org.jboss.ejb.Container.invoke(Container.java:712)<br> > >> at<br> > >> org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517)<br> > >> at<br> > >> org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:3 > <br> > >> 8<br> > >> 2)<br> > >> at > sun.reflect.GeneratedMethodAccessor35.invoke(Unknown <br> > >> Source)<br> > >> at<br> > >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccess > <br> > >> o<br> > >> rImpl.java:25)<br> > >> at > java.lang.reflect.Method.invoke(Method.java:324)<br> > >> at</font> > <br><font size=2 face="Courier New">>> > sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:261)<br> > >> at > sun.rmi.transport.Transport$1.run(Transport.java:148)<br> > >> at > java.security.AccessController.doPrivileged(Native Method)<br> > >> at > sun.rmi.transport.Transport.serviceCall(Transport.java:144)<br> > >> at<br> > >> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:46 > <br> > >> 0<br> > >> )<br> > >> at<br> > >> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport. > <br> > >> j<br> > >> ava:701)<br> > >> at > java.lang.Thread.run(Thread.java:536)<br> > >> Ciao,<br> > >> Jonathan O'Connor<br> > >> Development Manager<br> > >> XCOM Dublin<br> > >> Phone: +353 1 872 3305<br> > >> Mobile: +353 86 824 0736<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> > >><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> > ><br> > ><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> > ><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
