[infinispan-dev] Eviction overhaul

[Manik Surtani]

On 3 Apr 2009, at 10:15, Mircea Markus wrote:

> I see.
> Now, we have a data container in which we are assured (by  
> LockManager, right?) that we won't have concurrent writes on the  
> same key.
> I'm just thinking weather we need an CHM or something less (simple  
> HashMap?) for assuring consistency.

Well, like I said a regular HM will not allow concurrent modification  
to the structure.  Which is allowed by our LockManager as long as the  
keys are different.

>
> Cheers,
> Mircea
>
> Manik Surtani wrote:
>>
>> 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 <mailto:manik at jboss.org>
>>
>>
>>
>>
>

--
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/20090403/1bd56cbe/attachment-0001.html