[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