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

[Galder Zamarreno]

In this specific case, it was a second level cache for EJB3 entity beans, so I guess there's not much of a problem in evicting on undeployment.

This is a different use case to the one where you start JBC, state transfer occurs and you don't have all the classloaders. 

I guess another use for marshalling would be with isolated deployments, where JBC classloader is located in the default repository and u have several isolated applications populating that cache.

However, in this particular case about 2nd level cache redeployment, do you think it's necessary to use marshalling? A simple evict everything on undeployment would be sufficient. What do you think?

Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat


-----Original Message-----
From: Brian Stansberry 
Sent: 02 November 2006 16:58
To: Galder Zamarreno; 'jbosscache-dev at lists.jboss.org'
Subject: RE: [jbosscache-dev] easing the path for clients to getaroundredeployment class loading issues in JBC

Yeah, it works if it's OK that all the cached data was lost :-).  With a replicated cache, the node going through redeploy evicts everything but can then recover it from another node.  With local cache, it's evicted and gone.  Actually, not technically evicted, just removed w/o going through the interceptor chain.

If they want to keep the cached data, they'd need to store it in the cache as a byte[] or something and deserialize after redeploy. Or, use a non-passivating cache loader and recover from the cache loader.  Or use a passivating cache loader and manually evict() each node before undeploying.

Don't think I'll document this particular use, because calling inactivateRegion() as a shortcut for calling evict() is not really what the method's meant for.  But I'm sure the docs in general on how to use this could be improved.

Galder Zamarreno wrote:
> I have just tried it with a local cache and it worked.
> 
> One of the customers was using JBC 1.0, so the work was not in vain :)
> 
> It might be worth adding the redeployment case to the
> documentation in the marshaller section.
> 
> Galder Zamarreño
> Sr. Software Maintenance Engineer
> JBoss, a division of Red Hat
> 
> 
> -----Original Message-----
> From: jbosscache-dev-bounces at lists.jboss.org
> [mailto:jbosscache-dev-bounces at lists.jboss.org] On Behalf Of
> Galder Zamarreno
> Sent: 02 November 2006 16:31
> To: Brian Stansberry; jbosscache-dev at lists.jboss.org
> Subject: RE: [jbosscache-dev] easing the path for clients to
> getaroundredeployment class loading issues in JBC
> 
> I did suggest this to Manik, but he told me that marshalling
> would not work on local caches, but only in replicated ones.
> I might have misunderstood him.
> 
> The doc focuses on the state transfer issues when class
> loaders are not still available.
> 
> Galder Zamarreño
> Sr. Software Maintenance Engineer
> JBoss, a division of Red Hat
> 
> 
> -----Original Message-----
> From: Brian Stansberry
> Sent: 02 November 2006 15:58
> To: Galder Zamarreno; jbosscache-dev at lists.jboss.org
> Subject: RE: [jbosscache-dev] easing the path for clients to
> get aroundredeployment class loading issues in JBC
> 
> 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