JBAS-2142 and JBCACHE-273 Discussion Thread
brian.stansberry Aug 28, 2005 2:50 PMBen, Bela and I have been discussing how to enable "partial" fetching of TreeCache state. This feature would allow delayed (i.e. after the normal full state transfer that occurs when a cache is started) fetching of a portion of a cache's state.
The need for this feature specifically arises from the requirements of HttpSession replication, but once implemented it should be generally useful.
For HttpSession replication:
1) The same TreeCache instance is used to store sessions from multiple webapps. Each webapp stores its sessions in a separate branch (aka region) of the tree.
2) Proper unmarshalling of replicated sessions for a particular region requires the use of the appropriate webapp classloader. To support this, methods have been added to TreeCache to allow applications to register/unregister a classloader for a particular region.
3) The web service depends on the TreeCache, so the TreeCache will be started before webapps can register their classloaders. This makes using the existing state transfer mechanism to load state in a new cache problematic. (see JBAS-2142).
4) The webapps have a separate lifecycle from the cache. They can be undeployed. redeployed, new apps added etc. The TreeCache marshalling layer needs to be able to handle this. Specifically, if a given webapp is not currently deployed on a particular cluster node, that node's cache will not have access to the classloader needed to unmarshal replication events related to the app's cache region. The marshalling layer needs to be able to detect this situation and silently ignore replication messages for cache regions it ca't handle.
For background on the issue of using different classloaders to different unmarshal portions of the cache tree, see:
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=67858
To properly handle deployment of a webapp, the cache needs to expose an API allowing the app's JBossCacheManager to:
1) Register a classloader for a region.
2) "Activate" the region. This means:
a) Lock the region's parent node.
b) Fetch any existing state for the region from across the cluster and integrate it into the cache (i.e. add it to the parent).
c) Notify the TreeCacheMarshaller that it can begin normal handling of replication messages for the region.
d) Unlock the parent node.
To properly handle undeployment of a webapp, the cache needs to expose an API allowing the app's JBossCacheManager to:
1) "Inactivate" the region. This means:
a) Notify the TreeCacheMarshaller that it should begin suppressing handling of replication messages for the region.
b) Evict the region from the cache.
2) Unregister the webapp classloader from the region (to prevent leaking the classloader).
To support this, I propose adding the following methods to TreeCache:
public void activateRegion(String fqn) throws RegionNotEmptyException public void inactivateRegion(String fqn) throws RegionNameConflictException, CacheException public void fetchState(String fqn) throws RegionNotEmptyException
The methods needed for registering/unregistering ClassLoaders have already been added by Ben.
The fetchState(String fqn) method handles the cluster calls needed for partial state transfer. I'm not certain about exposing this method as public at this time. It doesn't need to be exposed to support the HttpSession replication use case, as a call to activateRegion calls through to fetchState. Actually, as I write this I don't see any use case for exposing it, but if anyone can, please let me know :)
I'll follow up with separate posts on various detail points.
Brian Stansberry
Developer, JBoss Clustering
JBoss, Inc.