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
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
Ph: 510-396-3864
skype: bstansberry
_______________________________________________
jbosscache-dev mailing list
jbosscache-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev