[jbosscache-dev] JBoss Cache weakness handling heuristic transaction outcomes - [Fwd: [Fwd: New case comment notification. Case Number 00017677]]

Tue Aug 21 10:41:06 EDT 2007


Manik Surtani wrote:
> Sorry about the slow response on this.
> 
> While making JBC an XA resource is on the roadmap, it isn't something 
> scheduled for any imminent release [1], as this is a pretty big change 
> for the JBC codebase (and more importantly, a big feature change which 
> would involve a lot of compatibility testing).
> 
> For the time being, treating STATUS_UNKNOWN as a rollback would help, 
> but only provided the database (and any other resources participating in 
> the tx) has rolled back as well.  Jonathan, correct me if I am wrong, 
> but there is no way to know this unless we are an XA resource as well, 
> am I right?
> 
> So is it reasonable to treat a STATUS_UNKNOWN as a rollback, and 
> document this limitation, until JBCACHE-70?

As far as I understood, there's two issues here:
- the fact that we through an ISE that messes the TM.
- the fact that we don't clear any locks being held, which leads to 
future lock timeout exceptions.

> 
> Cheers
> Manik
> 
> 
> 
> [1] http://jira.jboss.com/jira/browse/JBCACHE-70
> 
> 
> On 20 Aug 2007, at 13:49, Galder Zamarreno wrote:
> 
>> Forwarding to JBossCache dev.
>>
>> Manik et all,
>>
>> Thoughts on this?
>>
>> Cheers,
>>
>> -------- Original Message --------
>> Subject: [Fwd: New case comment notification.  Case Number 00017677]
>> Date: Thu, 16 Aug 2007 11:46:18 +0100
>> From: Jonathan Halliday <jonathan.halliday at redhat.com>
>> To: manik.surtani at jboss.com
>> CC: support-transactions at jboss.com, support-as at jboss.com
>>
>>
>> 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)
>>
>> -- 
>> Galder Zamarreño
>> Sr. Software Maintenance Engineer
>> JBoss, a division of Red Hat
>> _______________________________________________
>> jbosscache-dev mailing list
>> jbosscache-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
> 
> -- 
> Manik Surtani
> 
> Lead, JBoss Cache
> JBoss, a division of Red Hat
> 
> 
> 

-- 
Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat