[infinispan-dev] Management of shared caches

[Mircea Markus]

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.

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