Re: [infinispan-dev] Management of shared caches

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