<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On 3 Apr 2009, at 10:15, Mircea Markus wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>I see.<br>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.<br>I'm just thinking weather we need an CHM or something less (simple HashMap?) for assuring consistency.</div></blockquote><div><br></div><div>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.</div><br><blockquote type="cite"><div><br>Cheers,<br>Mircea<br><br>Manik Surtani wrote:<br><blockquote type="cite"><br></blockquote><blockquote type="cite">On 2 Apr 2009, at 09:10, Mircea Markus wrote:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite">Manik Surtani wrote:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Hello all.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">I have finished my work with the eviction code in Infinispan, here is a summary of what has happened.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">From a user perspective (including API and configuration) as well as a design overview, please have a look at<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><a href="http://www.jboss.org/community/docs/DOC-13449">http://www.jboss.org/community/docs/DOC-13449</a><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">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. :-)<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">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 :) .<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Some notes though: EvictionException is never used, same for SpinLock.rl field.<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Good point, EvictionException was a carry-over from JBC which can go away.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">SpinLock.rl was something I used for debugging/tracking race conditions - it should go away now as well.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite">And a question:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">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?).<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">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.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite">Isn't it possible to use the same locking (i.e. LockManager) for both these threads?<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">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:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">1. Acquire lock for key K1 in the lock manager<br></blockquote><blockquote type="cite">2. Write to K1<br></blockquote><blockquote type="cite">3. Sleep?<br></blockquote><blockquote type="cite">4. Commit:<br></blockquote><blockquote type="cite">5. Write changes to DC. This will lock the stripe in the CHM for the duration of this step only.<br></blockquote><blockquote type="cite">6. Release lock acquired in 1<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">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). <br></blockquote><blockquote type="cite">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.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">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.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite">(also, why are we using ConcurrentHashMaps in default container - isn't access to data guarded by the lock interceptor?<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">See above. :-)<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Cheers<br></blockquote><blockquote type="cite">Manik<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">--<br></blockquote><blockquote type="cite">Manik Surtani<br></blockquote><blockquote type="cite">Lead, JBoss Cache<br></blockquote><blockquote type="cite"><a href="http://www.jbosscache.org">http://www.jbosscache.org</a><br></blockquote><blockquote type="cite">manik@jboss.org <<a href="mailto:manik@jboss.org">mailto:manik@jboss.org</a>><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><br></div></blockquote></div><br><div apple-content-edited="true"> <span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-infinispantal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-infinispantal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>--</div><div>Manik Surtani</div><div>Lead, JBoss Cache</div><div><a href="http://www.jbosscache.org">http://www.jbosscache.org</a><br><a href="mailto:manik@jboss.org" target="_blank">manik@jboss.org</a></div><div><br></div></div></span><br class="Apple-interchange-newline"></div></span><br class="Apple-interchange-newline"> </div><br></body></html>