[infinispan-dev] Management of shared caches

[Brian Stansberry]

On 12/14/2009 01:12 PM, Mircea Markus wrote:
> yep, that's a good point indeed.
> Is there any other thing than reference counting that this release method would do?

The only other thing the AS impl of the JBC CacheManager[1] releaseCache 
does is deregistration from JMX. But I believe that's already handled in 
Infinispan.

OT, there are a couple other things [1] does:

1) Supports aliasing of configuratio names; I just created 
https://jira.jboss.org/jira/browse/ISPN-316 for that.

2) Lets you configure a list of caches to start when the manager starts. 
Idea was you deployed the cache at server start and took the startup 
time hit from the JGroups channel discovery then. If you redeploy the 
service using the cache (e.g. a webapp) the cache stays deployed so you 
don't need to take the discovery hit again.  AFAIK hasn't actually been 
used.

[1] 
http://anonsvn.jboss.org/repos/jbossas/projects/cluster/ha-server-cache-jbc/trunk/src/main/java/org/jboss/ha/cachemanager/CacheManager.java

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

Agreed. With JBC there was a major use case for sharing caches across 
unrelated applications. With Infinispan I don't see that being the case.

Also, CacheManager is an interface, so just like w/ JBC if the AS needs 
some special behavior it can have its own implementation and push stuff 
back upstream if appropriate.

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

Sounds good.

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


-- 
Brian Stansberry
Lead, AS Clustering
JBoss by Red Hat