[jbosscache-dev] Clear all data in destroy?

[Brian Stansberry]

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 at redhat.com
>>
>> _______________________________________________
>> jbosscache-dev mailing list
>> jbosscache-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
> 
> -- 
> Manik Surtani
> 
> Lead, JBoss Cache
> JBoss, a division of Red Hat
> 
> Email: manik at jboss.org
> Telephone: +44 7786 702 706
> MSN: manik at surtani.org
> Yahoo/AIM/Skype: maniksurtani
> 
> 


-- 
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry at redhat.com