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@lists.jboss.org

https://lists.jboss.org/mailman/listinfo/infinispan-dev

--

Manik Surtani

manik@jboss.org

Lead, Infinispan

Lead, JBoss Cache

http://www.infinispan.org

http://www.jbosscache.org

_______________________________________________

infinispan-dev mailing list

infinispan-dev@lists.jboss.org

https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________

infinispan-dev mailing list

infinispan-dev@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@lists.jboss.org

https://lists.jboss.org/mailman/listinfo/infinispan-dev

--

Manik Surtani

manik@jboss.org

Lead, Infinispan

Lead, JBoss Cache

http://www.infinispan.org

http://www.jbosscache.org

_______________________________________________

infinispan-dev mailing list

infinispan-dev@lists.jboss.org

https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________

infinispan-dev mailing list

infinispan-dev@lists.jboss.org

https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Manik Surtani
manik@jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org





_______________________________________________
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev