[infinispan-dev] Management of shared caches

Manik Surtani manik at jboss.org
Wed Dec 16 06:42:22 EST 2009 

On 16 Dec 2009, at 11:40, Mircea Markus wrote:

> 
> On Dec 16, 2009, at 11:11 AM, Manik Surtani wrote:
> 
>> 
>> On 15 Dec 2009, at 20:16, Brian Stansberry wrote:
>> 
>>> 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.
>> 
>> Yes, nice one - there will be some API impact though, how would one submit an alias map?  I wouldn't want injection to be the only path here.
> Coherence supports regexp for defining cache names. I guess that would also solve ISPN-316, be a more generic solution and also allow better migration from coherence. This won't work for runtime aliasing, not sure we'll be able to do this as well.

Regexps != aliases, although we could support both.

>> 
>>> 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.
>> 
>> Hm, each Cache shares the same Transport which is bound to the CacheManager.  So even if Caches start/stop, they won't incur the cost of rediscovery.  E.g.:
>> 
>> CacheManager cm = createNewCacheManager(); // no discovery here
>> c1 = cm.getCache("clustered cache 1"); // this will involve starting the Transport, and hence discovery
>> c2 = cm.getCache("clustered cache 2"); // no discovery here; cache1 already started the Transport
>> c1.stop();
>> cm.getCache("clustered cache 3") // again, discovery here; cache1 already started the Transport
>> 
>> HTH
>> Manik
>> 
>> 
>>> 
>>> [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
>>> _______________________________________________
>>> 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

More information about the infinispan-dev mailing list