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

[Manik Surtani]

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