WRT JBCACHE-1167 I'm writing a test to create this situation where JBC's Sync is called with a STATUS_UKNOWN and I notice that the OrderedSynchronizationHandler and DummyTransaction in JBoss Cache swallow any exceptions in afterCompletion(), simply logging the outcome. See http://fisheye.jboss.org/browse/JBossCache/core/tags/JBossCache_1_4_1_SP4... Lines 269 - 274. Makes unit testing pretty tough if the TM swallows the failure here. ;) Jonathan, how does JBossTS behave (or how should any TM behave) at this stage? I'm assuming keep the exception, set status to STATUS_UNKNOWN for the remaining syncs, and then throw the exception? Brian, how would this affect the BatchModeTM, which relies on the DummyTM? Do you ever have a case of more than one transaction participant in a "batch"?

Cheers, Manik On 16 Aug 2007, at 11:46, Jonathan Halliday wrote: > > Hi Manik > > Although this support issue is ultimately an Oracle problem, it does > expose a weakness in the JBoss Cache. Where an XA transaction has a > heuristic outcome, the status reported to the afterCompletion > synchronization is STATUS_UNKNOWN (5), since JTA does not handle > heuristics. In this case, the cache Synchronization fails to rollback > the cache tx. This leaves the app server in a bad (i.e. locked) state > even though the XA transaction has been resolved. > > At first glance it looks like the afterCompletion synchronization > should treat a STATUS_UNKNOWN as a cause for rollback as well as > logging the error as they currently do. Unfortunately the fix may be > more complex than that, since the db may have committed rather than > rolled back, meaning the cache would be out of sync with the db if you > rolled it back. What you really need is proper XA resources rather > than synchronizations for the cache, but that is a much bigger job. > > [ EAP 4.2, i.e. cache 1.4.1.SP3] > 2007-08-15 16:24:13,734,ERROR,,,,[OrderedSynchronizationHandler],JMS > SessionPool Worker-0,failed calling afterCompletion() on TxInte > rceptor.LocalSynchronizationHandler(gtx=GlobalTransaction:<10.25.98.165:3048>:2, > tx=TransactionImple < ac, BasicAction: a1962a5:be3: 46c36d0d:da > status: ActionStatus.COMMITTED >)^M > 11806 java.lang.IllegalStateException: illegal status: 5^M > 11807 at > org.jboss.cache.interceptors.TxInterceptor$RemoteSynchronizationHandler.afterCompletion(TxInterceptor.java:1088)^M > > 11808 at > org.jboss.cache.interceptors.TxInterceptor$LocalSynchronizationHandler.afterCompletion(TxInterceptor.java:1175)^M > > 11809 at > org.jboss.cache.interceptors.OrderedSynchronizationHandler.afterCompletion(OrderedSynchronizationHandler.java:83)^M > > 11810 at > com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.afterCompletion(SynchronizationImple.java:136)^M > > 11811 at > com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.afterCompletion(TwoPhaseCoordinator.java:340)^M > > > > Regards > > Jonathan. > > > > > -------- Original Message -------- > Subject: New case comment notification. Case Number 00017677 > Date: Thu, 16 Aug 2007 10:31:36 +0000 (GMT) > From: Jonathan Halliday <jhallida(a)redhat.com&gt; > To: support-as(a)jboss.com <support-as(a)jboss.com&gt; > > Jonathan Halliday has added a comment to case 00017677 : "JBoss 4.2 > and OracleXA Error - XAException.XAER_RMERR". Please read the comment > below and then click on the link to respond appropriately. > > Comment: > The logs show that Oracle is throwing an error during an XA commit. > Since it's in the second phase of the 2PC, this leads to a heuristic > outcome to the transaction. Unfortunately JBoss cache is not handling > this well, leading it to keep locks on some data. Subsequent errors > cascade from this. You need to take up the matter with DataDirect and > Oracle to determine why it's failing on the commit. > > spy(JMS SessionPool Worker-0)>> XAResource[5].commit(Xid xid, boolean > onePhase) > > spy(JMS SessionPool Worker-0)>> xid = > 131075-312D613139363261353A6265-613139363261353A626533 > > spy(JMS SessionPool Worker-0)>> onePhase = false > > JJH spy(JMS SessionPool Worker-0)>> *** XAException > javax.transaction.xa.XAException: [DataDirect][Oracle JDBC > Driver]Oracle XA Error Occurred. Native Error: 1 -3=XAER_RMERR *** > > javax.transaction.xa.XAException: [DataDirect][Oracle JDBC > Driver]Oracle XA Error Occurred. Native Error: 1 > > at com.ddtek.jdbcx.oracle.OracleImplXAResource.checkError(Unknown > Source) > > at com.ddtek.jdbcx.oracle.OracleImplXAResource.commit(Unknown Source) > > at com.ddtek.jdbcx.base.BaseXAResource.commit(Unknown Source) > > at com.ddtek.jdbcspy.SpyXAResource.commit(Unknown Source) > > at > org.jboss.resource.adapter.jdbc.xa.XAManagedConnection.commit(XAManagedConnection.java:175) > > > at > org.jboss.resource.connectionmanager.xa.JcaXAResourceWrapper.commit(JcaXAResourceWrapper.java:53) > > > at > com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelCommit(XAResourceRecord.java:487) > > > https://na1.salesforce.com/50030000003QAVl > > > > > -- > ------------------------------------------------------------ > Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod > Street, Windsor, Berkshire, SI4 1TE, United Kingdom. > Registered in UK and Wales under Company Registration No. 3798903 > Directors: Michael Cunningham (USA), Charlie Peters (USA) and David > Owens (Ireland) -- Manik Surtani Lead, JBoss Cache JBoss, a division of Red Hat _______________________________________________ jbosscache-dev mailing list jbosscache-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosscache-dev

Manik Surtani wrote: > WRT JBCACHE-1167 I'm writing a test to create this situation where > JBC's Sync is called with a STATUS_UKNOWN and I notice that the > OrderedSynchronizationHandler and DummyTransaction in JBoss Cache > swallow any exceptions in afterCompletion(), simply logging the > outcome. > See http://fisheye.jboss.org/browse/JBossCache/core/tags/ > JBossCache_1_4_1_SP4/src/org/jboss/cache/transaction/ > DummyTransaction.java?r=1566 Lines 269 - 274. > Makes unit testing pretty tough if the TM swallows the failure > here. ;) > Jonathan, how does JBossTS behave (or how should any TM behave) at > this stage? I'm assuming keep the exception, set status to > STATUS_UNKNOWN for the remaining syncs, and then throw the exception? If an afterCompletion throws an Exception the TS continues regardless, since all Synchronizations should be invoked. What the client sees is determined by the transaction outcome, not the behaviour of the afterCompletion syncs. The client will get an exception only if the beforeCompletion or XARresources misbehave, not it the afterCompletions do. Jonathan. _______________________________________________ jbosscache-dev mailing list jbosscache-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosscache-dev

No, the status is determined before any of the afterCompletions run and does not change. An afterCompletions success/failure does not change the transaction outcome. They are in effect receiving notification of an earlier event and the notifications are independent, may happen in arbitrary order or even in parallel. Well, aside from the use of TransactionSynchronizationRegistry, but that's another story. Jonathan. Manik Surtani wrote: > Ok, then the DummyTM's current behaviour of swallowing exceptions > in afterCompletion() is correct? > What about the status that gets passed into subsequent Syncs after > an exception is encountered? I'd expect something like (pseudocode): > int status = getStatusFromBeforeCompletion(); > for (Synchronization s : syncs) > { > try > { > s.afterCompletion(status); > } > catch (Exception e) > { > log(e); > status = STATUS_UNKNOWN; // so subsequent Syncs get this > status > } > } -- ------------------------------------------------------------ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA) and David Owens (Ireland)

Nope, not if the failure occurs in phase two. In that case you get heuristics, which the TS knows about internally but for which JTA has no Status. Hence we use STATUS_UNKNOWN. Jonathan. Manik Surtani wrote: > How, then, does a STATUS_UNKNOWN come about? > Any failure before afterCompletion() sequences commence (i.e., in > beforeCompletion()) should result in a rollback, right? > On 23 Aug 2007, at 11:09, Jonathan Halliday wrote: >> >> No, the status is determined before any of the afterCompletions >> run and does not change. An afterCompletions success/failure does >> not change the transaction outcome. They are in effect receiving >> notification of an earlier event and the notifications are >> independent, may happen in arbitrary order or even in parallel. >> Well, aside from the use of TransactionSynchronizationRegistry, >> but that's another story. >> >> Jonathan. >> >> Manik Surtani wrote: >>> Ok, then the DummyTM's current behaviour of swallowing >>> exceptions in afterCompletion() is correct? >>> What about the status that gets passed into subsequent Syncs >>> after an exception is encountered? I'd expect something like >>> (pseudocode): >>> int status = getStatusFromBeforeCompletion(); >>> for (Synchronization s : syncs) >>> { >>> try >>> { >>> s.afterCompletion(status); >>> } >>> catch (Exception e) >>> { >>> log(e); >>> status = STATUS_UNKNOWN; // so subsequent Syncs get this >>> status >>> } >>> } >> >> -- >> ------------------------------------------------------------ >> Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 >> Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. >> Registered in UK and Wales under Company Registration No. >> 3798903 Directors: Michael Cunningham (USA), Charlie Peters >> (USA) and David Owens (Ireland) > -- > Manik Surtani > Lead, JBoss Cache > JBoss, a division of Red Hat -- ------------------------------------------------------------ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA) and David Owens (Ireland)