[infinispan-dev] Eviction overhaul

[Manik Surtani]

On 2 Apr 2009, at 09:10, Mircea Markus wrote:

> Manik Surtani wrote:
>> Hello all.
>>
>> I have finished my work with the eviction code in Infinispan, here is  
>> a summary of what has happened.
>>
>> From a user perspective (including API and configuration) as well  
>> as a design overview, please have a look at
>> http://www.jboss.org/community/docs/DOC-13449
>>
>> From an implementation perspective, have a look at the srcs of  
>> FIFODataContainer and LRUDataContainer.  These two classes are  
>> where everything happens.  The javadocs should explain the details,  
>> but in a nutshell you can expect constant time operations for all  
>> puts, gets, removes, iterations.  :-)
>> Feedback on the impls would be handy.  :-)
> I like to concept - it's nice and clear for users to grasp. Also  
> took a look at implementation, nice and complex, so I'd rather have  
> you and a white board to understand it completely :) .
> Some notes though: EvictionException is never used, same for  
> SpinLock.rl field.

Good point, EvictionException was a carry-over from JBC which can go  
away.

SpinLock.rl was something I used for debugging/tracking race  
conditions - it should go away now as well.

> And a question:
> with this impl, we're doing locking twice for cache operations: on  
> LockInterceptor and on DataContainer itself. Why is this necessary?  
> I think this is needed so that eviction thread and user threads not  
> to conflict( am I right?).

Well, the locking is done on a different level.  The  
LockingInterceptor locks a key.  So keep in mind that 2 threads may  
lock 2 separate keys concurrently, but these may map to the same hash  
bucket in the data container.  In which case, since the DC uses a CHM,  
this would mean that the same stripe is locked preventing concurrent  
reorganisation of the stripe.

> Isn't it possible to use the same locking (i.e. LockManager) for  
> both these threads?

Possible, but again not ideal, for example if you have TX 1 which  
writes to key K1.  The way this currently works, here is what happens:

1.  Acquire lock for key K1 in the lock manager
2.  Write to K1
3.  Sleep?
4.  Commit:
5.  Write changes to DC.  This will lock the stripe in the CHM for the  
duration of this step only.
6.  Release lock acquired in 1

Now if you have a concurrent write to K2, which *happens* to be in the  
same stripe as K1 in the CHM, this second thread will *not* block for  
TX 1 since TX 1 only locks the CHM stripe for a short duration (step 5  
above).

Now if we used the same locks thoughout (e.g., step 1 *is* the lock  
stripe in the CHM) then you have far less concurrency.

Of course, the above premise only holds true if you have enough shared  
locks for the lock manager such that K1 and K2 do not map to the same  
lock, even if they are in the same stripe in the CHM.  Also holds true  
if lock striping is disabled and you have a lock per key.

> (also, why are we using  ConcurrentHashMaps in default container -  
> isn't access to data guarded by the lock interceptor?

See above.  :-)

Cheers
Manik

--
Manik Surtani
Lead, JBoss Cache
http://www.jbosscache.org
manik at jboss.org




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