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

[Manik Surtani]

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

--
Manik Surtani

Lead, JBoss Cache
JBoss, a division of Red Hat