RE: [jbosscache-dev] JBCACHE-388 Provide modified data incallbacks
by Brian Stansberry
How about a variation on Ben's idea of providing an enum to specify the
type of change? Sample API follows.
/**
* Called before and after a {@link Node} is modified. Data passed in
the
* <code>modData</code> param can be used to determine what was
modified.
* <p/>
* When called with <code>pre == true</code>, <code>modData</code> is
the
* initial state of the {@link Node} before modification.
* <p/>
* When called with <code>pre == false</code>, the contents of
<code>modData</code>
* depend on the value of <code>modTtype</code>:
* <ul>
* <li><b>PUT_KEY_VALUE</b>: Map contains the single key/value pair that
was added.</li>
* <li><b>REMOVE_KEY_VALUE</b>: Map contains the single key/value pair
that was removed.</li>
* <li><b>PUT_MAP</b>: Map contains the new state of the {@link Node}
following modification.
* This map includes modified key/value pairs as well as any that were
not affected.</li>
* </ul>
* <p/>
* Implementations interested in seeing the difference in the node data
in the PUT_MAP case
* can cache the <code>modData</code> map passed when <code>pre ==
true</code>, and then
* when the <code>pre == false</code> callback is received, pass the
cached map and the new
* <code>modData</code> to {@link
org.jboss.cache.util.Util.diffNodeData(Map pre, Map post)}.
*
* @param fqn Fqn of the node being modified
* @param pre <code>true</code> if the modification is about to be
applied,
* <code>false</code> if it has already been applied
* @param isLocal <code>true</code> if the modification originated
locally,
* <code>false</code> if it was replicated from another
node
* @param modType PUT_KEY_VALUE, REMOVE_KEY_VALUE or PUT_MAP
* @param modData Unmodifiable {@link Map}; will not be
<code>null</code>. See
* description above.
*/
public void nodeModified(Fqn fqn, boolean pre, boolean isLocal,
ModificationType modType, Map modData);
public class Util {
public static MapModifications diffNodeData(Map pre, Map post) {
// do the diff here
}
public static class MapModifications {
public Map addedEntries;
public Map removedEntries;
public Map modifiedEntries;
}
}
Advantage here is JBC goes to little effort to support this, so overhead
is low if the listener isn't interested. CacheListener impls that are
interested in modifications, but where the app never calls put(Fqn, Map)
also have very little overhead. I believe Jerry's DistributedState is
such a case. The big overhead of doing the diff is only incurred by
CacheListener impls that care, and we provide much of the code to do it
for them.
- Brian
Jerry Gauthier wrote:
> This issue is relevant for DistributedState in AS 5.0 where
> the implementation was rewritten to use TreeCache for the
> underlying replicated store. There's currently a mismatch
> between the events published by DistributedState and those offered by
> TreeCache. Specifically, DistributedState identifies the data key and
> new value for modified categories (which are TreeCache
> nodes); it also identifies keys that are removed. Currently
> it's not possible to obtain this information from TreeCache
> unless the subscriber responds to the "pre"
> and "post" modification events by retrieving the modified
> node's Map before/after and then performing a diff operation.
>
> I've looked at the new CacheListener interface and it looks
> like it helps a little since it provides the Map as part of
> the event. But as Ben pointed out, it's still necessary for
> the subscriber to diff the maps to determine what was
> changed. So this doesn't appear to help significantly for
> DistributedState as the hard part is performing the diff, not
> retrieving the map.
>
> Jerry
>
>
>>>> "Brian Stansberry" <brian.stansberry(a)jboss.com> 10/30/06 11:33 AM
>>>>
> How common is the use case where the listener wants to know
> the differences? I'd be concerned about the overhead of
> creating objects to encapsulate the diff every time there is
> a change -- just so those objects can be passed to a
> CacheListener that ignores the data.
>
> OTOH, even if the current approach of just handing out the
> new data map is used, that should at least be a
> Collections.unmodifiableMap wrapping the internal data
> structure, so there's overhead there as well.
> Probably
> a wash, except in the put(Fqn, Map) case, where doing the diff is
> more tedious.
>
> I guess I have no strong opinion on this...
>
> jbosscache-dev-bounces(a)lists.jboss.org wrote:
>> Hmm, which approach do people prefer?
>>
>> And how would a nodeModified event from an operation like put(Fqn,
>> Map) be represented, since it may represent both data added as well
>> as data modified? I don't think this should result in multiple
>> callbacks.
>>
>> Cheers,
>>
>>
>>> Yes, I did realize that. But implementation wise, it should be
>>> straightforward since Cache knows exactly the identifier, right? We
>>> just need to add an "identifier" enum in the nodeModified callback.
>>> Downside is one more parameter but upside is faster processing such
>>> that we don't hog the calling thread.
>>>
>>> -----Original Message-----
>>> From: Manik Surtani [mailto:msurtani@redhat.com]
>>> Sent: Monday, October 30, 2006 11:15 PM
>>> To: Ben Wang
>>> Cc: jbosscache-dev(a)lists.jboss.org
>>> Subject: Re: [jbosscache-dev] JBCACHE-388 Provide modified data in
>>> callbacks
>>>
>>> Well, nodeModified covers 3 scenarios:
>>>
>>> 1) Data added to map
>>> 2) Data removed from map
>>> 3) Existing map data changed
>>>
>>> if we just passed in deltas, we'd also need to pass in keys to
>>> describe the operation. I.e., a nodeVisited event could pass in a
>>> key-value pair, but we'd also need to pass in an identifier to
>>> describe the modification. Which makes it pretty tedious.
> This is
>>> why I opted for just passing a snapshot of the state of data before
>>> and after the mod.
>>>
>>>
>>> --
>>> Manik Surtani
>>>
>>> Lead, JBoss Cache
>>> JBoss, a division of Red Hat
>>>
>>> Email: msurtani(a)redhat.com
>>> Telephone: +44 7786 702 706
>>> MSN: manik(a)surtani.org
>>> Yahoo/AIM/Skype: maniksurtani
>>>
>>>
>>>
>>> On 29 Oct 2006, at 16:20, Ben Wang wrote:
>>>
>>>> Yes, are are right. Silly me, I was looking at the pre only.
>>>>
>>>> Still, my question is that will it make more sense during post-
>>>> nodeModified notification to deliver only the data modified (not
>>>> the new data map). If I am only interested what portion of my data
>>>> has been modified (and I belive this is a quite common use case),
>>>> then I would need to keep an old data map and diff it with the new
>>>> data map. Doable but it would be a performance killer for sure.
>>>>
>>>> Thanks,
>>>>
>>>> -Ben
>>>>
>>>> -----Original Message-----
>>>> From: Manik Surtani [mailto:msurtani@redhat.com]
>>>> Sent: Friday, October 27, 2006 11:14 PM
>>>> To: Ben Wang
>>>> Cc: jbosscache-dev(a)lists.jboss.org
>>>> Subject: Re: [jbosscache-dev] JBCACHE-388 Provide modified data in
>>>> callbacks
>>>>
>>>> Is this when pre is true or false?
>>>>
>>>> If pre is true, the data will be the old data. If pre is false,
>>>> it will be the new data. -- Manik Surtani
>>>>
>>>> Lead, JBoss Cache
>>>> JBoss, a division of Red Hat
>>>>
>>>> Email: msurtani(a)redhat.com
>>>> Telephone: +44 7786 702 706
>>>> MSN: manik(a)surtani.org
>>>> Yahoo/AIM/Skype: maniksurtani
>>>>
>>>>
>>>>
>>>> On 27 Oct 2006, at 13:47, Ben Wang wrote:
>>>>
>>>>> Manik,
>>>>>
>>>>> Can you clarify the semantics for the modified callbacks?
>>>>> Specifically, I am looking at the test case:
>>>>> CacheListenerTest.testRemoveData()
>>>>> calling
>>>>> cache.remove(fqn, "key2");
>>>>> Still has the nodeModified() coming with the original data map.
>>>>> Is this the expected behavior?
>>>>>
>>>>> I am hoping to see a semantics that bundles exactly the modified
>>>>> data.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> -Ben
>
> _______________________________________________
> jbosscache-dev mailing list
> jbosscache-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
19 years, 9 months
RE: [jbosscache-dev] easing the path for clients to getaroundredeployment class loading issues in JBC
by 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(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
19 years, 9 months
RE: Use of org.jboss.cache.Region
by Brian Stansberry
Manik Surtani wrote:
> On 1 Nov 2006, at 20:07, Brian Stansberry wrote:
>
>> Another thing we need is equiv of the
>> o.j.c.eviction.RegionManager.markNodeCurrentlyInUse()/
>> unmarkNodeCurrentl yInUse() calls exposed in o.j.c.Region.
>
> What are these markers used for? And what semantics would we need
> around this?
>
They are used by the LRUPolicy (and potentially others that implement
the feature) so the policy will ignore a node the app has marked "in
use".
Illustration of use by EJB3 SFSB:
1) User accesses bean.
2) StatefulTreeCache fetches bean from cache using get(). If no
transactional context at this point, RL from the get is released as soon
as method returns.
3) StatefulTreeCache call markNodeCurrentlyInUse
4) User invokes method on bean that takes a long time.
5) Eviction thread kicks in. Would ordinarily evict the bean since the
get() in #2 happened a while ago. But the node-in-use event tells it
not to.
6) User invocation finishes, bean is released.
7) StatefulTreeCache calls unmarkNodeCurrentlyInUse.
8) Bean can now be evicted on later eviction thread run.
I'd thought the changes were discussing of moving the lock interceptor
up in the order might help, but they don't -- as mentioned in step 2,
the bean can be "in use" long after any lock is held on its cache node.
Semantics we'd need are pretty much what we have now in 1.4 -- when
method is invoked, if the region is configured for eviction, create an
EvictedEventNode object and put it in the event queue. Only difference
is RegionManager doesn't get involved to find the region -- the app
should do that itself via the Cache API.
19 years, 9 months
RE: Use of org.jboss.cache.Region
by Brian Stansberry
Another thing we need is equiv of the
o.j.c.eviction.RegionManager.markNodeCurrentlyInUse()/unmarkNodeCurrentl
yInUse() calls exposed in o.j.c.Region.
Brian Stansberry wrote:
> Hey Manik,
>
> I know you were planning on working with integrating the
> eviction and marshalling regions this week. Here's some
> input based on stuff I'm doing on converting the EJB3 code to use the
> 2.0 API.
>
> 1) Once I call Cache.getRegion(fqn, true) I've created a
> Region, but I'm not sure how to set it up programatically to
> do eviction. Passing a config to setEvictionPolicyConfig()
> seems obvious. But would that be enough to get the eviction
> policy created? Or should I then call activate()? The
> javadoc implies that activate() pertains to marshalling, but
> does it make sense to make it apply to eviction as well -- a
> sort of general purpose start() method?
>
> 2) Conversely, how to remove a region when an SFSB is
> undeployed? There's no Cache.removeRegion(Fqn). There is a
> deactivate() method.
>
> I realize this stuff may not be implemented; I'm more
> concerned with understanding the API.
>
> Brian Stansberry
> Lead, AS Clustering
> JBoss, a division of Red Hat
> Ph: 510-396-3864
> skype: bstansberry
19 years, 9 months
RE: [jbosscache-dev] JBC head tests
by Ben Wang
Oops! Sorry, fresh check out solves the second problem.
Thanks,
-Ben
-----Original Message-----
From: Manik Surtani [mailto:msurtani@redhat.com]
Sent: Friday, November 03, 2006 6:30 PM
To: Ben Wang
Cc: jbosscache-dev(a)lists.jboss.org
Subject: Re: [jbosscache-dev] JBC head tests
On 3 Nov 2006, at 04:09, Ben Wang wrote:
> Manik,
>
> JBC head is not running correctly for replication since the last two
> days or so. It is difficult to see what got changed because of JBC
> fisheye is not available. Should we ask QA to put it up again?
Yes, see Galder's comment. Use http://viewvc.jboss.com for now.
>
> Also would you mind to look into this problem first? Even a simple
> replicated.SyncReplTest failed.
Eh, these seem to work fine here. Even on CC:
http://cruisecontrol.jboss.com/cc/artifacts/jboss-cache-testsuite/
20061102235206/results/index.html
>
> Thanks a lot,
>
> -Ben
>
> _______________________________________________
> jbosscache-dev mailing list
> jbosscache-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
19 years, 9 months
RE: [jbosscache-dev] Use of isStandalone field in TreeCache
by Brian Stansberry
Ahh, I understand now. This is legacy stuff. The serviceName property
in 1.x was not a config attribute, but rather was set by the JMX server
via a callback when the cache was registered in JMX. So testing if it
was null was a way of testing whether the cache was already registered.
That's no longer the way it works, so I'm going to remove this logic.
jbosscache-dev-bounces(a)lists.jboss.org wrote:
> The isStandalone field in TreeCache is giving me a bit of trouble in
> TreeCache.
>
> It's usage seems to be "check if the
> Configuration.serviceName property is null/empty. If it's
> not, don't register the cache with JMX".
>
> I'm not sure what the use case for this behavior is, but it's
> causing hassles for me. With the MC, objects are no longer
> registered automatically with JMX. So, I'm counting on the
> cache registering itself. (Actually, I have no choice -- the
> API leaves no other clean way to get it registered.) But, I
> don't want to use the default ObjectName JBC uses, so I need
> to set the serviceName property. But if I do that, the cache
> is no longer getting registered.
>
> Brian Stansberry
> Lead, AS Clustering
> JBoss, a division of Red Hat
> Ph: 510-396-3864
> skype: bstansberry
>
> IT executives: Red Hat still #1 for value
> http://www.redhat.com/promo/vendor/
19 years, 10 months
Use of isStandalone field in TreeCache
by Brian Stansberry
The isStandalone field in TreeCache is giving me a bit of trouble in
TreeCache.
It's usage seems to be "check if the Configuration.serviceName property
is null/empty. If it's not, don't register the cache with JMX".
I'm not sure what the use case for this behavior is, but it's causing
hassles for me. With the MC, objects are no longer registered
automatically with JMX. So, I'm counting on the cache registering
itself. (Actually, I have no choice -- the API leaves no other clean way
to get it registered.) But, I don't want to use the default ObjectName
JBC uses, so I need to set the serviceName property. But if I do that,
the cache is no longer getting registered.
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
Ph: 510-396-3864
skype: bstansberry
IT executives: Red Hat still #1 for value
http://www.redhat.com/promo/vendor/
19 years, 10 months
JBC head tests
by Ben Wang
Manik,
JBC head is not running correctly for replication since the last two days or so. It is difficult to see what got changed because of JBC fisheye is not available. Should we ask QA to put it up again?
Also would you mind to look into this problem first? Even a simple replicated.SyncReplTest failed.
Thanks a lot,
-Ben
19 years, 10 months
RE: [jbosscache-dev] JBC head tests
by Galder Zamarreno
I asked that four days ago:
Tom Benninger replied with:
"Galder,
We've run into a bug in Fisheye. Fisheye crashes when it tries to parse a recent update to CVS. I'm working on trying to figure out why presently, and as soon as we have a fix, CVS will be available again.
In the mean time, you may want to see if http://viewvc.jboss.org/cgi-bin/viewvc.cgi/ provides the functionality you need.
Sorry about the inconvenience."
http://viewvc.jboss.org/cgi-bin/viewvc.cgi/ for the moment then.
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 Ben Wang
Sent: 03 November 2006 05:10
To: jbosscache-dev(a)lists.jboss.org
Subject: [jbosscache-dev] JBC head tests
Manik,
JBC head is not running correctly for replication since the last two days or so. It is difficult to see what got changed because of JBC fisheye is not available. Should we ask QA to put it up again?
Also would you mind to look into this problem first? Even a simple replicated.SyncReplTest failed.
Thanks a lot,
-Ben
_______________________________________________
jbosscache-dev mailing list
jbosscache-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev
19 years, 10 months
RE: [jbosscache-dev] easing the path for clients to getaroundredeployment class loading issues in JBC
by Brian Stansberry
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
19 years, 10 months