Re: JBoss Cache weakness handling heuristic transaction outcomes - [Fwd: [Fwd: New

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

--
Manik Surtani

Lead, JBoss Cache
JBoss, a division of Red Hat

_______________________________________________
jbosscache-dev mailing list
jbosscache-devlists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev

Re: JBoss Cache weakness handling heuristic transaction outcomes - [Fwd: [Fwd: New

Thread: Re: JBoss Cache weakness handling heuristic transaction outcomes - [Fwd: [Fwd: New