Sorry I've been out of this for a while (kind of shelved 2.0.0 issues
so I could clear the stack of stuff sitting on top 1.3.0.SP4 and then
On 15 Nov 2006, at 14:51, Brian Stansberry wrote:
The purpose of this method is to allow an application to signal the
eviction policy to not evict a particular node who's data it's using.
Needed in situations where the app doesn't hold a lock on the node
where evicting the node will cause a problem.
AFAICT, this use case is really just for EJB3 SFSBs, where the problem
is that evicting an "in-use" node forces the container to call
prePassivate() on the in-use EJB. This is done from a CacheListener.
This is all a bit funky. Adding methods to the API to deal with a
specific use case. It also has a small race condition, which I won't
get into here.
Here's a different (but still funky) approach:
Add a new exception class o.j.c.eviction.NodeInUseException extends
The application implements CacheListener. When it gets a
nodePassivated(pre=true) event, if it doesn't want the passivation, it
throws the NodeInUseException. This will abort the eviction and
propagate back to the eviction policy. Eviction policies are already
written such that they catch all exceptions, and then throw the node
into a retry queue (see BaseEvictionAlgorithm.evictCacheNode()). If we
wanted to get fancy, we could specifically catch NodeInUseException
decide from there whether to add it to the retry queue.
I don't think we should try to change this this week; more of a short
term future thing.
Your second (and still funky) approach does seem a lot cleaner than
hacking in stuff into the API for a very specific use case. So
certainly my preferred option. But from a performance standpoint, is
this really an "exceptional" circumstance?
Lead, AS Clustering
JBoss, a division of Red Hat
IT executives: Red Hat still #1 for value
jbosscache-dev mailing list