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 *and*
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 very
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
RuntimeException.
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 and
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.
Thoughts?
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/