[infinispan-dev] Passivation and BCHM WAS: fixing eviction with transactions (critical for Hibernate Search)

[Manik Surtani]

This has an added implication on Galder's recent fix re: @CacheEntryPassivated -> @CacheEntriesPassivated notifications.

With this fix, these notifications *cannot* be batched as they will happen once per entry, as and when the entry is removed from memory.

So we now have @CacheEntryPassivated again.  So is there any point in a @CacheEntriesEvicted as well?  :-)  My gut feel is still yes.
 
On 10 Jun 2011, at 13:42, Manik Surtani wrote:

> So I've taken on this sub-task from Sanne (ISPN-1169), and here is the deal:
> 
> BCHM analyses whether or not to evict stuff every time an operation (put, get, replace) is run, based on the configured eviction policy (LIRS, LRU or NONE).  It does so by calling evictionStrategy.execute(), which returns a Set of hash entries removed from the BCHM.
> 
> https://github.com/infinispan/infinispan/blob/master/core/src/main/java/org/infinispan/util/concurrent/BoundedConcurrentHashMap.java#L341
> 
> Note that execute() actually removes entries from the BCHM, so after execute() is called, these entries are no longer in the BCHM!
> 
> This is set is then sent to the EvictionManager 
> 
> https://github.com/infinispan/infinispan/blob/master/core/src/main/java/org/infinispan/eviction/EvictionManager.java#L61
> 
> which in turn passivates the evicted entries:
> 
> https://github.com/infinispan/infinispan/blob/master/core/src/main/java/org/infinispan/eviction/EvictionManagerImpl.java#L189
> 
> So we have a window where the entry is neither accessible from memory or from a cache store, since it is "in-fly".
> 
> My proposed fix is to:
> 
> 1) Make sure the PassivationManager is passed in to the DataContainer, and available to any EvictionStrategy
> 2) EvictionStrategies ensure passivation occurs *before* removing an entry from the BCHM
> 3) The additional window of a reader thread in the ActivationInterceptor determining that an entry is in memory and bypasses activation, only to find that the entry has been removed from the BCHM by the time it gets to it, should not be a problem since when testing the DataContainer in the ActivationInterceptor, the entry is placed in the caller's InvocationContext so a handle on the entry is there.
> 
> Does anyone have any concerns with this?  Vladimir, does this adversely affect the BCHM/EvictionStrategy design?
> 
> Cheers
> Manik
> 
> On 8 Jun 2011, at 19:15, Vladimir Blagojevic wrote:
> 
>> On 11-06-08 12:10 PM, Sanne Grinovero wrote:
>>> Yes, we're on the same channel now. That's exactly what I meant
>>> yesterday on IRC when mentioning the BoundedCHM, and what I meant
>>> above with "we should acquire it before it's actually evicted".
>>> But this issue is getting complex, I've split it in 4 different
>>> problems and I'm going to solve the first three soon, the BoundedCHM
>>> is the fourth and I'm not sure I'll fix that today.
>> Sanne,
>> 
>> Sounds good, please consult us when it comes to changing BCHM!
>> 
>> Cheers.
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> 
> --
> Manik Surtani
> manik at jboss.org
> twitter.com/maniksurtani
> 
> Lead, Infinispan
> http://www.infinispan.org
> 
> 
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Manik Surtani
manik at jboss.org
twitter.com/maniksurtani

Lead, Infinispan
http://www.infinispan.org



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20110610/db783af9/attachment.html