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(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> --
> Manik Surtani
> manik(a)jboss.org
> Lead, Infinispan
> Lead, JBoss Cache
>
http://www.infinispan.org
>
http://www.jbosscache.org
>
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org