[jbosscache-dev] Clear all data in destroy?

[Manik Surtani]

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 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