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

[Jonathan Halliday]

Yep that looks good.

Jonathan.

Manik Surtani wrote:
> Jonathan,
> 
> If you reckon this works, let me know and I'll go ahead and confirm the 
> fix.  It is checked in to SVN:
> 
>     http://anonsvn.jboss.org/repos/jbosscache/core/branches/1.4.0-GA/
>     http://anonsvn.jboss.org/repos/jbosscache/core/branches/1.4.0-GA/tests/functional/org/jboss/cache/transaction/StatusUnknownTest.java 
> 
>     http://anonsvn.jboss.org/repos/jbosscache/core/branches/1.4.0-GA/src/org/jboss/cache/interceptors/TxInterceptor.java    
> 
> 
> Cheers,
> Manik
> 
> 
> On 23 Aug 2007, at 17:51, Manik Surtani wrote:
> 
>> 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
>>
>>
>>
> 
> -- 
> Manik Surtani
> 
> Lead, JBoss Cache
> JBoss, a division of Red Hat
> 
> 
> 


-- 
------------------------------------------------------------
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)