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

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 _______________________________________________ jbosscache-dev mailing list jbosscache-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosscache-dev