[infinispan-dev] Management of shared caches

[Brian Stansberry]

On 12/16/2009 05:42 AM, Manik Surtani wrote:
>
> 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.

That could be a later enhancement, though, right? Or is this something 
you'd want in the 1.0.0 API?

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

Ah, good point. This is where the analogue to JBC breaks down; the JBC 
CacheManager shares nothing across Cache instances; the Infinispan 
CacheManager is more like a JBC Cache with a nice API for 
configuring/managing Regions.

Complex environments like the AS may need to deploy/manage multiple 
CacheManagers to support multiple Channels. Although JGroups ergonomics 
improvements may eliminate the primary requirement for that.

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