[infinispan-dev] Clarification on ISPN-649

[Galder Zamarreño]

Hi,

It seems like there's some confusion about what https://jira.jboss.org/browse/ISPN-649 is trying to fix. Let me explain this in further detail:

Paul found some issues with redeployment of JPA apps and 2nd level cache (see http://opensource.atlassian.com/projects/hibernate/browse/HHH-5563 - currently offline btw). Basically, when SessionFactories are shutdown, all caches are stopped but in an AS environment, the CacheManager keeps running since it's deployed as a shared resource. Upon redeployment and retrieving the caches from the CacheManager, this were in TERMINATED state which meant that no replication happened between them. However, you could, as a client make modifications on those caches if these were local, and you could retrieve data without probs. Obviously, this shouldn't be the case.

Paul's suggestion was that in the 2LC, the code would check the status of the cache and if it was in TERMINATED state, restart it (he actually implemented the condition checking if invocations were allowed, but don't think it's a good idea since other temporary statuses would lead to restarts, i.e. INITIALIZING and that could cause issue).

I disagree with Paul in that such check and restart should be done in DefaultCacheManager. So, DCM, whenever someone calls any of getCache(), it would check whether the cache is TERMINATED, and if it is, it would restart it. After thinking this, I started to consider other possibilities: What happens if the client holds a ref to Cache and someone else stops it? IMO, CacheDelegate should protect against it and if it's TERMINATED, it should restart itself.

Finally, I also considered what would happen if not only Cache was stopped, but DCM was stopped as well. What happens when you call getCache()? When testing this, I discovered that it was returning TERMINATED caches as well. So then I considered whether DCM should attempt to restart itself, but I decided not to do this cos most of the initialisation happens in the ctror, so it's not designed to be restarted. As a result, DCM now throws an IllegalStateException if you call getCache() and it's TERMINATED. Same thing happens with Cache if it discovers that not only it's TERMINATED, but the CacheManager to which it belongs is terminated and this way we cover for cached Cache instances.

So, to sum up:
- Caches can be restarted by either DCM or the Cache instances themselves if they see them as TERMINATED.
- CacheManager's cannot be restarted. Instead a new instance needs to be created.

Hope this clarifies the issue. Please find a patch containing the fix for this. It includes a test case with the possibilities mentioned above:

-------------- next part --------------
A non-text attachment was scrubbed...
Name: If_stopped,_Caches_can_now_be_restarted__CacheContainers_still_need_recreating_after_being.patch
Type: application/octet-stream
Size: 13677 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/infinispan-dev/attachments/20100915/4fb3aec1/attachment-0001.obj 
-------------- next part --------------


Cheers,
--
Galder Zamarre?o
Sr. Software Engineer
Infinispan, JBoss Cache