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

Ok, so here is the fix I propose. Index: TxInterceptor.java =================================================================== --- TxInterceptor.java (revision 4310) +++ TxInterceptor.java (revision 4311) @@ -1076,7 +1076,8 @@ runCommitPhase(gtx, tx, modifications, onePhaseCommit); log.debug("Finished commit phase"); break; - + case Status.STATUS_UNKNOWN: + log.warn("Received JTA STATUS_UNKNOWN in afterCompletion()! XA resources may not be in sync. The app should manually clean up resources at this point."); case Status.STATUS_MARKED_ROLLBACK: case Status.STATUS_ROLLEDBACK: log.debug("Running rollback phase"); Log a warning and then treat as a rollback. Does this make sense? On 22 Aug 2007, at 12:00, Manik Surtani wrote: > Sure. I suspect they would already deal with this in such a > manner anyway, given that this is how Hibernate deals with > STATUS_UNKNOWN. > > > On 22 Aug 2007, at 11:33, Jonathan Halliday wrote: > >> >> The client app will actually get a heuristic exception in >> response to its commit call and should do cleanup in the >> exception handler. However, that's not always going to be user >> code, it may be e.g. the app server's EJB container in the case >> of CMT. Hence if you go down this route, which I agree is >> probably the best approach, other parts of the app server may >> need to be aware of the issues. >> >> Jonathan. >> >> Manik Surtani wrote: >>> +1. So the controlling app - which would typically be a >>> participant in the tx anyway - would react to a STATUS_UNKNOWN >>> by clearing the cache of the nodes involved. The cache itself >>> just treats STATUS_UNKNOWN as a rollback. >>> On 21 Aug 2007, at 19:01, Jason T. Greene wrote: >>>> Manik Surtani wrote: >>>>> Ok, I just spoke to Steve @ Hibernate on how Hibernate deals >>>>> with this situation. From an IM conversation: >>>>> "that is deemed a failed transaction >>>>> anything other than committed" >>>>> So Hibernate rolls back STATUS_UNKNOWN as well. I think this >>>>> is therefore a safe default. >>>>> Is there a good reason to try and purge the nodes in such a >>>>> case? Or just stick with the default above? >>>> >>>> I think this makes more sense for the cache controlling >>>> application to be responsible for removing data. If you look at >>>> the hibernate case it does stuff outside the realm of the tx >>>> boundary anyway (putForExternalRead). So even if we did auto >>>> purge, it's not guaranteed that we are purging the correct data. >>>> >>>> -- >>>> Jason T. Greene >>>> Lead, POJO Cache >>>> JBoss, a division of Red Hat >>> -- >>> 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 >> >> >> -- >> ------------------------------------------------------------ >> 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 Lead, JBoss Cache JBoss, a division of Red Hat