[jbosscache-dev] Region.markNodeCurrentlyInUse

[Brian Stansberry]

Manik Surtani wrote:
> 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?
> 

For a man with no rhythm I come up with a lot of funky stuff. ;)

Should be an exceptional circumstance.  The bean would have to be in use
longer than the configured timeToLiveSeconds. That can be configured per
bean class via an annotation and defaults to 300 seconds.  IMO an EJB
configured to passivate in less time than it's expected to be used in a
tx is a misconfigured EJB.

There would probably be a small performance pickup by getting rid of the
mark/unmarkNodeInUse calls every time an SFSB is pulled from the
cache/returned to the cache.

One thing to think more about is whether the LRUPolicy should queue the
node for eviction retry if it catches this exception, or just let it go
and wait for the node to be evicted again via the regular path.
Queueing for retry increases the chances that the node will still be in
use a few seconds later when the eviction runs again, causing another
exception would be thrown.  Need to check if not retyring risks leaking
nodes.