I'm not sure whether this got sent in the end or not.
Galder ZamarreƱo
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat
-----Original Message-----
From: Galder Zamarreno
Sent: 02 November 2006 11:44
To: jbosscache-dev(a)lists.jboss.org
Subject: easing the path for clients to get around redeployment class loading issues in
JBC
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