[jbosscache-dev] Clear all data in destroy?

[Brian Stansberry]

Very good point; I think some kind of control to prevent calls going 
through when not STARTED is very important.  Same issue applies to 
replicated calls.

This opens a bunch of design questions, i.e. how do you handle open 
transactions during a call to stop()?  Give them a couple seconds to 
clear and then abort if needed? Or immediately abort? Vladimir did some 
stuff in this area for FLUSH.

Manik Surtani wrote:
> 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
> 
> 
> 
> 


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