Using the testbeds from above on CR3 shows a significant improvement over CR2. The source for the tests can be found here: http://www.robotsociety.com/cache/cr3/src.rar NB: These tests are micro-benchmarks, i.e. not a real-life scenario. Parallel tests Reading threads access all available nodes concurrently. Reading throughput was improved by 27%. All threads are still mostly blocked. I'm not sure how much concurrency we can claim here. Threads: http://www.robotsociety.com/cache/cr3/parallell_threads.GIF Dedicated tests Four threads all read from a dedicated node. There is one node per thread so they should never try to read from the same node. Reading throughput was improved by 40%. Thread concurrency is clearly improved which can be seen in the profiler as well. Threads comparison: http://www.robotsociety.com/cache/cr3/comparison.GIF It seems that in the parallel scenario, most threads are blocked by the initLock in UnversionedNode. The lock is lazily initiated in case we don't need locking, but on the other hand you then force a synchronized upon every threads that wants to get the lock reference. The synchronization is only to check if the lock has been initialized and when it has it really serves no purpose, so arguably this could be solved without having to synchronize on every getLock() call. However, using non-lazy initialization and removing the sync block did not result in any significantly higher concurrency since the next mutex is in the tryLock on the lock that we pass back. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4063426#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...