I assume by 'external lock management' that you are manually controlling the lock pin/unpin calls (or are you reducing the number of locks, and coping with the drop in throughput on collisions?). There have a couple of recent developments on this, and it's looking like we're probably going to do away with the pin/unpin functionality for TC locks... There are some developments in the enterprise (non OS code) that alleviate some of these problems in the L2, and I think the server team were doing some work on optimizing the way that locks are stored in the server... but I've not been following that too closely.
Chris On Nov 29, 2010, at 1:22 AM, Sergio Bossa wrote: > Resolved by using the NullLockStrategy and implementing my own > external lock management. > > Anyways, I still think a disk-based lock store would be the way to > go for easily scale up. > > Sergio Bossa > Sent by iPhone > > Il giorno 25/nov/2010, alle ore 19:20, Sergio Bossa <sergio.bo...@gmail.com > > ha scritto: > >> Hi Chris and other TC guys, >> >> I know this is a pretty old post but I'm running into problems again >> with the LockStore implementation, and unfortunately, this time it >> doesn't seem to be a bug. >> >> The LockStore behavior seems to be the one described by Chris as >> follows: >> >>> In your case although you have 2M entries, you will only have at >>> most as >>> many locks in the L2 as there are live values in the L1s. (The >>> actual >>> number could be less than this due to hash collisions, and the >>> possibility >>> of live objects that have no associated greedy lock). >> >> The problem now is that I have ~3M total entries (using a toolkit map >> rather than ehcache but this shouldn't make any difference), and ~2M >> live entries into L1s heaps: this is causing the LockStore on the L2 >> to hold 2M locks (confirmed by heap dumps) and take one third of the >> total heap, which is pretty huge. >> My biggest concern here is that 2M live entries are not that much at >> all, and that L1s scale pretty poorly this way because limited by L2 >> memory requirements; even by using the enterprise Server Array, we >> would need tens of servers just to store 10M - 20M objects! >> >> So, are there any plans to reduce LockStore memory footprint? Maybe a >> disk-based implementation? >> >> -- >> 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 _______________________________________________ tc-dev mailing list tc-dev@lists.terracotta.org http://lists.terracotta.org/mailman/listinfo/tc-dev
