Re: [jbosscache-dev] Clear all data in destroy?

Good point. http://jira.jboss.com/jira/browse/JBCACHE-1084 Since we intend to bypass the interceptor chain for this call, I presume we do a root.removeChildrenDirect() and root.clearDataDirect(). What guarantees have we got that once stop() is called, no existing threads are working on the dataset? I suppose this is more of a lifecycle question - when the CacheStatus is set to STOPPING, do we have any checks that prevent invocations on the cache? Perhaps a check in the CallInterceptor before making a call to the cache, barfing with a CacheException if needed? - Manik On 30 May 2007, at 17:57, Brian Stansberry wrote: > Hmm, I was thinking destroy too, but here's a use case for stop. > > Cache is a 2nd level cache. No state transfer on startup, they just > want a cold cache. > > Some problem is happening so they stop the cache and then start again. > Now they're out of sync with the cluster, i.e. missed any updates to > their cached data that occurred while they were stopped. > > Basically, the state transfer semantics imply that the in-memory state > is "consistent" with the cluster when start returns. Either its > "consistent" because it's been transferred, or it's "consistent" > because it's empty and waiting to be populated from a trusted source > (shared cache loader or external source like db). Leaving the > in-memory state around after stop() breaks that. > > Manik Surtani wrote: >> Makes sense to me, probably in destroy() rather than stop(), wdyt? >> On 30 May 2007, at 17:14, Brian Stansberry wrote: >>> Shouldn't destroy() clear all data from the in-memory cache? Or >>> maybe stop()? IMHO if you destroy a cache and then call create/start >>> again you shouldn't see the old data. >>> >>> Not advocating doing anything fancy here, i.e. anything that goes >>> through the interceptor chain. Simple clearing of the data and >>> children maps on the root node. >>> >>> --Brian Stansberry >>> Lead, AS Clustering >>> JBoss, a division of Red Hat >>> brian.stansberry(a)redhat.com >>> >>> _______________________________________________ >>> jbosscache-dev mailing list >>> jbosscache-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jbosscache-dev >> --Manik Surtani >> Lead, JBoss Cache >> JBoss, a division of Red Hat >> Email: manik(a)jboss.org >> Telephone: +44 7786 702 706 >> MSN: manik(a)surtani.org >> Yahoo/AIM/Skype: maniksurtani > > > --Brian Stansberry > Lead, AS Clustering > JBoss, a division of Red Hat > brian.stansberry(a)redhat.com