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

[Galder Zamarreno]

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