On Wed, Apr 28, 2010 at 4:50 PM, Tim Eck <t...@terracottatech.com> wrote:
> I believe the lock strategy in ehcache is hashcode based -- the hashcode > of the key determines the lock ID. > [CUT] > Active locks are in memory but they are much smaller in recent TC releases > (like 3.2.1 for example). So, it's like saying there will be one lock per key/value, and so, I'm still curious how you manage, in the latest tim-concurrent-collections release, to keep the number of locks in LockStore growing and growing: that is, I have a test with 100% inserts, but the number of locks grows very slowly (around 200k locks with around 2M entries). > Chris would know better than I would, but I > think locks are in memory for any keys read/put by that VM and for which > the value is not flushed. Any other locks should be GC'd. This isn't clear to me: what do you mean by "flushed"? Maybe you mean that when a value is flushed from *all* L1s, its lock will be GC'd? But then what happens when the value is faulted back? Is the lock created again? Thanks much! -- Sergio Bossa http://www.linkedin.com/in/sergiob _______________________________________________ tc-dev mailing list tc-dev@lists.terracotta.org http://lists.terracotta.org/mailman/listinfo/tc-dev
