[jbosscache-dev] Re: Use of org.jboss.cache.Region

[Manik Surtani]

On 6 Nov 2006, at 15:28, Brian Stansberry wrote:

> 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.

Ok - not the prettiest, exposing control over how evictions work in  
client API.  But yeah, necessary...

http://jira.jboss.com/jira/browse/JBCACHE-834