Manik Surtani wrote:
On 1 Nov 2006, at 20:07, Brian Stansberry wrote:
> Another thing we need is equiv of the
> o.j.c.eviction.RegionManager.markNodeCurrentlyInUse()/
> unmarkNodeCurrentl yInUse() calls exposed in o.j.c.Region.
What are these markers used for? And what semantics would we need
around this?
They are used by the LRUPolicy (and potentially others that implement
the feature) so the policy will ignore a node the app has marked "in
use".
Illustration of use by EJB3 SFSB:
1) User accesses bean.
2) StatefulTreeCache fetches bean from cache using get(). If no
transactional context at this point, RL from the get is released as soon
as method returns.
3) StatefulTreeCache call markNodeCurrentlyInUse
4) User invokes method on bean that takes a long time.
5) Eviction thread kicks in. Would ordinarily evict the bean since the
get() in #2 happened a while ago. But the node-in-use event tells it
not to.
6) User invocation finishes, bean is released.
7) StatefulTreeCache calls unmarkNodeCurrentlyInUse.
8) Bean can now be evicted on later eviction thread run.
I'd thought the changes were discussing of moving the lock interceptor
up in the order might help, but they don't -- as mentioned in step 2,
the bean can be "in use" long after any lock is held on its cache node.
Semantics we'd need are pretty much what we have now in 1.4 -- when
method is invoked, if the region is configured for eviction, create an
EvictedEventNode object and put it in the event queue. Only difference
is RegionManager doesn't get involved to find the region -- the app
should do that itself via the Cache API.