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

Manik Surtani manik at jboss.org
Tue Aug 21 10:54:25 EDT 2007


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?

What do you guys think?

Cheers,
--
Manik Surtani

Lead, JBoss Cache
JBoss, a division of Red Hat






More information about the jbosscache-dev mailing list