Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@jackrabbit.apache.org
Received-SPF: pass (athena.apache.org: local policy includes SPF record at
 spf.trusted-forwarder.org)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.co.uk;
  h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:From:To:Subject:Date:Message-ID:MIME-Version:Content-Type:X-Mailer:Thread-Index:Content-Language;
  b=buJz9GmJndHx+ZSCdhVtJl7BZ1XY+09OFjiSO835F6Srmh5aTZhA9V3qfiyZUbuc1QJaeP6Euj6/0hUofj3cUGp7IsSLZqirHrOWnrk68jzMd88XYIMJwfFFvsW734HKHMqq/PnXoOeHWSWkHJsK3fU71ZhMeMd8H9j9Q9XzMtk=
  ;
From: "sbarriba" <sbarriba@yahoo.co.uk>
To: <users@jackrabbit.apache.org>
Subject: JackRabbit Caching: BundleCache vs ItemManager vs CacheManager
Date: Mon, 30 Jun 2008 09:24:41 +0100
Message-ID: <00d001c8da8a$bf8278c0$3e876a40$@co.uk>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_00D1_01C8DA93.2146E0C0"
Thread-Index: Acjaiou05qKRzEdcRBu0HL6wUX/jbg==
Content-Language: en-gb

------=_NextPart_000_00D1_01C8DA93.2146E0C0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

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

 
------=_NextPart_000_00D1_01C8DA93.2146E0C0--