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

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