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/