[jboss-jira] [JBoss JIRA] Closed: (JBCACHE-1058) Cache lifecycle methods can be invoked twice

Cache lifecycle methods can be invoked twice -------------------------------------------- Key: JBCACHE-1058 URL: http://jira.jboss.com/jira/browse/JBCACHE-1058 Project: JBoss Cache Issue Type: Feature Request Security Level: Public(Everyone can see) Affects Versions: 2.0.0.CR1 Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: 2.0.0.CR2 The separation of the CacheJmxWrapper from the Cache itself creates an inherent risk of invoking lifecycle methods twice in a microcontainer environment. For example: 1) MC constructs a Cache. 2) MC injects Cache into a CacheJmxWrapper, registers wrapper in JMX. 3) MC sees Cache exposes create() so it calls Cache.create(). 4) MC see CacheJmxWrapper exposes create() so it calls CacheJmxWrapper.create(). 5) CacheJmxWrapper.create() passes the call on to Cache.create(), so Cache.create() is called twice. To deal with that, I coded CacheJmxWrapper so it wouldn't pass a create() call on to the wrapped cache if the cache was dependency injected. Then added JBCACHE-1047 as a help to people doing the above programatically who wouldn't blindly do step #3 above like the MC will. But, all that's no good, because in the microcontainer case, since CacheJmxWrapper doesn't pass lifecycle calls through to the cache, user's can't create/start/stop/destroy the underlying cache via JMX. A better solution is to either: 1) Have Cache expose information about what state it is in in terms of lifecycle transitions. CacheJmxWrapper then decides whether to pass the call on to Cache based on that state (e.g. don't pass on a create() call if the Cache is created or started). 2) Have Cache track information about what state it is in in terms of lifecycle transitions. Cache itself ignores redundant lifecycle calls. I suppose #2 is better as it's better encapsulated. Either one really depends on doing JBCACHE-928.