[ https://issues.jboss.org/browse/ISPN-905?page=com.atlassian.jira.plugin.s... ] Manik Surtani updated ISPN-905: ------------------------------- Summary: Enhance cache management methods on EmbeddedCacheManager (was: CacheManager.cacheExists(String cache), CacheManager.getCacheIfExists(String cache), and Cache.exists()) Description: These should include: {code:borderStyle=solid} boolean cacheExists(String cache) Cache<?, ?> getCacheIfExists(String cache) boolean remove(String Cache) {code} Original request: {quote} There seems to be no ability to check if a populated cache exists through both CacheManager and through Cache (=is this still a valid handle) and to get a cache if it exists. {quote} was:There seems to be no ability to check if a populated cache exists through both CacheManager and through Cache (=is this still a valid handle) and to get a cache if it exists. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-905?page=com.atlassian.jira.plugin.s... ] Galder Zamarreño reassigned ISPN-905: ------------------------------------- Assignee: Galder Zamarreño (was: Manik Surtani) -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-905?page=com.atlassian.jira.plugin.s... ] Work on ISPN-905 started by Galder Zamarreño. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-905?page=com.atlassian.jira.plugin.s... ] Patrick McFarland commented on ISPN-905: ---------------------------------------- As far as I can tell, Cache.stop() would only delete the contents if it is local only, and not written to disk; nor does running Cache.stop() on one cluster member effect other cluster members, their Cache instances remain started. Cache.remove() should stop the cache on all members of the cluster and also delete whats on disk (if it is backed by a persistent disk store). Indeed, having a cache defined in the config would not effect this either way. (cacheExists()/getCacheIfExists()) should return (true/the cache) if has been started (locally) and/or has data written to disk (cluster wide). If it is neither started locally nor any cluster member has a disk store for it, then it should return (false/null). I also agree that stop() should also be transaction safe; I already assumed it was from the way IS is designed. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-905?page=com.atlassian.jira.plugin.s... ] Patrick McFarland commented on ISPN-905: ---------------------------------------- Well, Infinispan already has an event system due to the listeners. If I was planning this out, all Cache instances would listen for a global stop event, and then stop (as if the local node called stop); this does require stop to be TX safe, however (as in, the actual stop, as currently executed, cannot stop until all pending TX are committed; however no new TX can be started during this state as well). .remove() would spam a global stop event, and then spam a "delete the cache on disk" event, which cannot complete unless all cache instances have indeed stopped. The reason I request cacheExists/getCacheIfExists is because I intend on abusing Infinispan for it's clustering abilities to be a higher performance persistent KV store. Caches themselves back large objects. Even in my code the name assigned to the Cache variable in my code is "store" not "cache". -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-905?page=com.atlassian.jira.plugin.s... ] Patrick McFarland commented on ISPN-905: ---------------------------------------- Yeah, re-entrant stuff would be problematic. It obviously should be implemented in a way that actually makes sense for how Infinispan works internally. Basically, I do not want to use JGroups directly or do stupid tricks with Infinispan events. Since my caches specifically started from my application are stores for my objects, the only way to delete the object is to delete the cache that backs them too (as in, CacheManager.remove()); however, there is no way to force my application to _not_ re-create caches. As in, if I hand out instances of my objects (which front end the caches), there is no way to perform an analog of .remove() on them unless I can tell Infinispan to _never_ re-create the cache that backs my objects if it doesn't already exist. So, if I do MyObjectManager.remove(myObject) (yes, my API looks familiar), which calls CacheManager.remove(cache), there is no sane way to tell Infinispan that I do not wish to re-create the cache I just removed, and there is no way for me to check from within MyObject's logic that the backing cache is still valid (in which if its not valid, I would raise an exception). To me, using an API that works like cacheExists()/getCacheIfExists() is the most flexible for people who use Infinispan this way. Listening to events to catch the .remove() event cannot be easily added in a way that is both transaction safe (as enforced by Infinispan) and will never ever leak data (as in, the accidental re-creation of the cache that belongs to a now removed MyObject). -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-905?page=com.atlassian.jira.plugin.s... ] Patrick McFarland commented on ISPN-905: ---------------------------------------- Manik brought up a good point on IRC... AtomicMapLookup uses getAtomicMap(cache, key, boolean createIfAbsent) as the API style instead of getAtomicMapIfExists(cache, key). I think getCacheIfExists might be better done as getCache(name, boolean createIfAbsent) to match the existing API style. The functionality is otherwise exactly the same. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-905?page=com.atlassian.jira.plugin.s... ] Galder Zamarreño updated ISPN-905: ---------------------------------- Description: These should include: {code:borderStyle=solid} boolean cacheExists(String cache) // Old: Cache<?, ?> getCacheIfExists(String cache) Cache<?, ?> getCache(String cache, boolean createIfAbsent) boolean remove(String Cache) {code} Original request: {quote} There seems to be no ability to check if a populated cache exists through both CacheManager and through Cache (=is this still a valid handle) and to get a cache if it exists. {quote} was: These should include: {code:borderStyle=solid} boolean cacheExists(String cache) Cache<?, ?> getCacheIfExists(String cache) boolean remove(String Cache) {code} Original request: {quote} There seems to be no ability to check if a populated cache exists through both CacheManager and through Cache (=is this still a valid handle) and to get a cache if it exists. {quote} -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-905?page=com.atlassian.jira.plugin.s... ] Galder Zamarreño resolved ISPN-905. ----------------------------------- Resolution: Done -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-905?page=com.atlassian.jira.plugin.s... ] Galder Zamarreño resolved ISPN-905. ----------------------------------- Resolution: Done Fixed getCache() call ambiguity in Scala modules. Applied change in 4.2.x as well. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-905?page=com.atlassian.jira.plugin.s... ] SBS JIRA Integration updated ISPN-905: -------------------------------------- Forum Reference: http://community.jboss.org/message/591865#591865, http://community.jboss.org/message/592436#592436 (was: http://community.jboss.org/message/592436#592436) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira