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 1.4.1) 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 > *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? 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?