Hi all, Having looked through the 1.5 Release Notes (http://www.apache.org/dist/jackrabbit/RELEASE-NOTES-1.5.0.txt) I see the group has been working hard. I can't see any obvious changes - without looking at the code - which would alleviate the contention issues we've seen around ItemManager and the (MySql)PersistenceManager. I see the following is still a known issue.
[JCR-1846] Jackrabbit thread contention issue due to fat lock Can anyone comment if there's been any significant concurrency improvements in this area? Regards, Shaun -----Original Message----- From: sbarriba [mailto:[email protected]] Sent: 30 June 2008 09:25 To: [email protected] Subject: JackRabbit Caching: BundleCache vs ItemManager vs CacheManager Hi all, As output from the concurrency investigation we've dug into the caching and contention within JackRabbit. So far our understanding is: ... PersistenceManager Cache: o The "bundleCacheSize" determines how many nodes the PersistenceManager will cache. As this determines the lifetime of the references to the temporary BLOB cache if its not large enough BLOBs will be continually read from the database (if using externalBlobs=false). o Configurable in <PersistenceManager> XML block o Default size 8MB o This cache is shared by all sessions. o Synchronised access using the ISMLocking stategy e.g. Default or FineGrained ... Session ItemManager Cache: o Items are cached from the underlying persistence manager on a per session basis. o Limit cannot be set. o Uses a ReferenceMap which can be emptied by the JVM GC as required o Synchronised access using the itemCache object ... CacheManager Cache: o Limit can only be set programmatically via the Workspace cacheManager o http://wiki.apache.org/jackrabbit/CacheManager o Defaults to 16MB o Its not clear as yet how the CacheManager relates, if at all, to the ItemManager cache 2 questions: ... What is the purpose of the CacheManager and which caches does it actually control? ... For example, for a workspace with 100,000 nodes what is an appropriate setting for the Cache Manager? We were originally using a PooledSessionInView pattern for our application but we've now found that this means we see synchronisation on the BundleCache as we do not benefit from the Session Cache. It seems the Java GC cleans up the ItemManager cache fairly aggressively. Using a GlobalSessionInView pattern (sharing a single session across threads) also doesn't really help as it moves the contention to Session ItemManager instead of the Persistence Manager. ...which implies that a SharedSession per X Views is probably the best pattern e.g. a limited number of threads sharing a single session to stripe the contention. It would seem like JackRabbit would benefit from some consolidation of caching to use a library such as ehcache etc which provides more fine-grained and consistent control over the various caching layers and configuration mechanisms. All comments welcome. Regards, Shaun
