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

[Manik Surtani]

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?



On 21 Aug 2007, at 16:47, Manik Surtani wrote:

> Or just a configuration entry.  :-)  I just don't like introducing  
> config entries in SPs.
>
>
> On 21 Aug 2007, at 16:37, Galder Zamarreno wrote:
>
>>
>>
>> Manik Surtani wrote:
>>> No - by purge, I mean remove all affected nodes from the cache,  
>>> thereby assuming that the cache is backed by a DB and will be  
>>> populated again.
>>
>> Ok, I understood now. Sounds like a good solution but not sure  
>> whether it should be configured via a system property. Bearing in  
>> mind that there can be several JBC instances running in AS, do we  
>> want to make this a global thing for all of them? Some of these  
>> instances might have DBs in the back, i.e. HB 2nd level cache  
>> (which is the customer's use case) or not, as in the HTTP session  
>> repl cache.
>>
>> A workaround like this could work thought:
>>
>>  -D<cache_instance_name>.tx.heuristic_outcome_purge = true
>>
>> Thoughts?
>>> On 21 Aug 2007, at 16:10, Galder Zamarreno wrote:
>>>>
>>>>
>>>> Manik Surtani wrote:
>>>>> On 21 Aug 2007, at 15:44, Jonathan Halliday wrote:
>>>>>> Manik Surtani wrote:
>>>>>>> Sorry about the slow response on this.
>>>>>>> While making JBC an XA resource is on the roadmap, it isn't  
>>>>>>> something scheduled for any imminent release [1], as this is  
>>>>>>> a pretty big change for the JBC codebase (and more  
>>>>>>> importantly, a big feature change which would involve a lot  
>>>>>>> of compatibility testing).
>>>>>>> For the time being, treating STATUS_UNKNOWN as a rollback  
>>>>>>> would help, but only provided the database (and any other  
>>>>>>> resources participating in the tx) has rolled back as well.   
>>>>>>> Jonathan, correct me if I am wrong, but there is no way to  
>>>>>>> know this unless we are an XA resource as well, am I right?
>>>>>>
>>>>>> Actually in heuristic outcomes you still won't necessarily  
>>>>>> know what the db did. The transaction manger will tell you  
>>>>>> what it decided, but not what each individual resource  
>>>>>> actually did. For that you would need JBossTS specific code  
>>>>>> rather than general XAResource code. You can partially address  
>>>>>> that by making the cache the last resource but you won't  
>>>>>> eliminate it entirely.
>>>>>>
>>>>>>> So is it reasonable to treat a STATUS_UNKNOWN as a rollback,  
>>>>>>> and document this limitation, until JBCACHE-70?
>>>>>>
>>>>>> yes, or toss anything that is affected out of the cache and  
>>>>>> let it be reread from the db on the next tx, which would  
>>>>>> prevent you ever getting out of sync. Or course that assumes  
>>>>>> the data is backed by some store e.g. the db, which is the  
>>>>>> case only for EJBs. General purpose use of the cache is a more  
>>>>>> difficult case.
>>>>> Perhaps a switch for this behaviour?  By default, do a  
>>>>> rollback, unless -Dorg.jboss.cache.tx.heuristic_outcome_purge =  
>>>>> true?
>>>>
>>>> By purge, you mean?
>>>> - rollback modifications
>>>> - and commit the tx
>>>>
>>>>> What do you guys think?
>>>>> Cheers,
>>>>> -- 
>>>>> Manik Surtani
>>>>> Lead, JBoss Cache
>>>>> JBoss, a division of Red Hat
>>>>
>>>> -- 
>>>> Galder Zamarreño
>>>> Sr. Software Maintenance Engineer
>>>> JBoss, a division of Red Hat
>>> -- 
>>> Manik Surtani
>>> Lead, JBoss Cache
>>> JBoss, a division of Red Hat
>>
>> -- 
>> Galder Zamarreño
>> Sr. Software Maintenance Engineer
>> 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

--
Manik Surtani

Lead, JBoss Cache
JBoss, a division of Red Hat