[jbosscache-dev] DummyTransaction and DumyTransactionManager

Brian Stansberry brian.stansberry at redhat.com
Wed Aug 22 15:53:50 EDT 2007 

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?
> 
> 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"?
> 

Right now, no, but we certainly could in the future.

1) Single web request spans HttpSession cache and SFSB cache. On web 
request entry Tomcat valve starts at BTM tx.  On exit, Tomcat valve 
commits tx, thus triggering replication from both HttpSession cache and 
SFSB cache.

2) Similar thing for cross-context web request; i.e. request spans two 
wars.  This would only be an issue if we supported an architecture where 
different wars could use different underlying JBC instances.

Both of these use cases could be eliminated by a really good 
region-based cache impl, but it would have to be both really good and 
timely.

- Brian

> 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 at redhat.com>
>> To: support-as at jboss.com <support-as at jboss.com>
>>
>> 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev


-- 
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry at redhat.com

More information about the jbosscache-dev mailing list