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

[Manik Surtani]

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