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

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.

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

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.

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

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

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. >>>>>> >>>>>> -- >>>>>> 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 >>> >>> >>> -- >>> 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 _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev