[infinispan-dev] Management of shared caches

[Manik Surtani]

On 14 Dec 2009, at 19:12, Mircea Markus wrote:

> yep, that's a good point indeed.
> Is there any other thing than reference counting that this release method would do?
> TBH I think the 3) suggestion should be okay, and the users should be aware that they should only  all stop() from one thread only. That is because the cache is rather a collection of data rather than a connection to something, and destroying it shouldn't be done each time you access it but only at the beginning and the end of your app.

For now, absolutely.  I don't see us implementing any reference counting for 4.0.  Maybe in future, it might be useful though.

> 
> On Dec 14, 2009, at 12:33 PM, Manik Surtani wrote:
> 
>> This is a good point, Brian.
>> 
>> Perhaps Cache.stop() should delegate to CacheManager.stopCache(cacheName) and as you say, some form of reference counting may be in order.  
>> 
>> However, calling CacheManager.stopCache(cacheName) could be overloaded (a boolean "force" flag?) to stop the cache, regardless of known references?
>> 
>> Cheers
>> Manik
>> 
>> 
>> On 11 Dec 2009, at 20:37, Brian Stansberry wrote:
>> 
>>> Had a look at DefaultCacheManager today and I see it has no mechanism 
>>> for controlling the stopping of shared caches. Multiple independent 
>>> callers to getCache("foo") can get a ref to the foo cache, and then any 
>>> of them can call stop() on it.
>>> 
>>> A few possibilities come to mind:
>>> 
>>> 1) Add a releaseCache method, do some reference counting, and stop the 
>>> cache when all refs are released. Remove the cache from the "caches" map.
>>> 
>>> 2) And/or, wrap the cache in a wrapper whose stop() method doesn't call 
>>> through to the wrapped cache until stop() is called on all wrappers
>>> 
>>> 3) Advise in the javadoc that shared caches are supported, but if they 
>>> are used it's the users responsibility to ensure that at least one but 
>>> only one caller calls stop() on the cache. At least for the AS use 
>>> cases, this should be OK, since an Infinispan Cache will be analogous to 
>>> a JBC Region, and there's only one user for a given region.
>>> 
>>> -- 
>>> Brian Stansberry
>>> Lead, AS Clustering
>>> JBoss by Red Hat
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> 
>> --
>> Manik Surtani
>> manik at jboss.org
>> Lead, Infinispan
>> Lead, JBoss Cache
>> http://www.infinispan.org
>> http://www.jbosscache.org
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> 
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Manik Surtani
manik at jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org