Hi, I've been reading the source code of both EHCache and JCS to find out which one to use in my project.
I found that, EHCache locks the entire cache (via synchronizing on the Cache in a get() call. In this synchronized block the code checks both the memory map and the disk map, along with all the management and logging code. JCS, on the other hand, only synchronizes on the memory cache's get() call of the region, excluding the management code (updating counters, logging, etc.). In other words, the job done in the synchronized block is less than the one in EHCache, hence more suitable for multi-threaded, concurrent access environments. This is enough evidence for me to conclude that JCS is better for my project. However, I would like to ask the authors of JCS why they ever use locking of an entire region at all. I've been looking at the ConcurrentHashMap source of the JDK 6, and saw that they have two nice features: 1) The map is divided into segments which allow for partial locking of the entire map. This way, during concurrent access, all the map is not locked, even for brief moments, but portions of it. 2) The locking is done only for a very brief amount of time, during access to the value of the stored element. No management overhead. This is acceptable. I think both features above are essential for a caching system. Currently, the whole region is locked during every get (although the implementation is better than EHCache). No segments, longer locking duration compared to ConcurrentHashMap. I wonder why JCS authors did not implement these ideas. Am I missing something ? Regards, Bulent Erdemir --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
