[jbosscache-dev] easing the path for clients to get aroundredeployment class loading issues in JBC

[Brian Stansberry]

There's already an API for this kind of use case. I'm going to speak in 1.x terms here:

// Config for cache startup
TreeCache.setUseRegionBasedMarshalling(true);
TreeCache.inactiveOnStartup(true); // suppresses initial state transfer

// Deploy phase -- app creates a region and registers it's classloader
TreeCache.registerClassloader(Fqn, ClassLoader);
// Then transfer the state for the region, since you've now go the correct classloader
TreeCache.activateRegion(Fqn);

// Operate normallly

// Undeploy phase -- deactivate the region, which evicts all nodes
TreeCache.inactivateRegion(Fqn)
// Don't leak a classloader ref
TreeCache.unregisterClassloader(Fqn);

- Brian

jbosscache-dev-bounces at lists.jboss.org wrote:
> Hi,
> 
> I have seen couple of people with the same issue in the past
> few weeks. I already had a chat with Manik but it was more
> about solving the problem at the time rather than thinking
> how we can make it easier for the customers to get around it.
> 
> Applications which are redeployed and interact with the cache
> are quite likely to encounter class loading issues. They tend
> to enter data in the cache, they get redeployed, try
> accessing the data entered previously and you end up with a
> ClassCastException. 
> 
> For caches managed by Hibernate, this is not a problem cos
> Hibernate does the cleanup on undeployment, asking clients to close
> the session. 
> 
> In the rest of cases, clients have to iterate over evict()
> calls. This will be solved in JBC 2.0 with evictSubtree() method that
> can be recursive. 
> 
> However, clients still need to code an MBean which is part of
> the lifecycle of the deployment, and upon destroy, it calls
> evictSubtree(). 
> 
> The cache configuration would have to depend on this MBean in
> case the cache deployment is done inside the client's
> application. Otherwise, we could assume that undeployment of
> JBC is quite likely due to AS undeployment in which case there's no
> need for cleanup. 
> 
> Have you got any ideas of anything else that could be done in
> JBC to help speed up this implementation and make it less of
> daunting task for the customer?
> 
> I guess the main part is documenting all this.
> 
> Galder Zamarreño
> Sr. Software Maintenance Engineer
> JBoss, a division of Red Hat
> 
> 
> 
> _______________________________________________
> jbosscache-dev mailing list
> jbosscache-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev



Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
Ph: 510-396-3864
skype: bstansberry