Jackrabbit 1.5 improvements?: BundleCache vs ItemManager vs CacheManager

[sbarriba <sb...@yahoo.co.uk>]

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:sbarriba@yahoo.co.uk] 
Sent: 30 June 2008 09:25
To: users@jackrabbit.apache.org
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

 

 

 

 

 

Re: Jackrabbit 1.5 improvements?: BundleCache vs ItemManager vs CacheManager

[Marcel Reutegger <ma...@gmx.net>]

sbarriba wrote:
> I see the following is still a known issue.
> 
> [JCR-1846] Jackrabbit thread contention issue due to fat lock 

this issue is fixed in 1.5.2 and 1.4.7. See also 'fix versions' in issue tracker.

regards
 marcel