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(a)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(a)lists.jboss.org > [mailto:jbosscache-dev-bounces@lists.jboss.org] On Behalf Of > Galder Zamarreno > Sent: 02 November 2006 16:31 > To: Brian Stansberry; jbosscache-dev(a)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(a)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(a)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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosscache-dev