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