jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Boston <...@tfd.co.uk>
Subject Re: Jackrabbit performance in multi threaded environment
Date Sun, 21 Nov 2010 19:03:57 GMT
Try upgrading to 2.1.2
There was a lot of work done to remove synchronization, however IIRC, reads that need to load
items that are not in the shared cache block other reads that need to do the same, and writes
block all reads of that form.  (see the non exclusive read locks/ and write locks in the SharedItemManager)

Also, depending on what you ACLs do (if you have any denies) you might find that there is
a system session underlying the standard AccessControlManager that is shared by all sessions,
and blocks all other sessions..... although this might have been one of the things removed
in 2.1.2.

I have found node creation that also creates version history to be particularly expensive
in a multithreaded environment, leading to creating version histories (adding mix:versionable)
only when the first version is saved. 

As I say, most of my observations are for 2.1.1 and may have been fixed in 2.1.2.
On 10 Nov 2010, at 14:44, kazim_ssuet@yahoo.com wrote:

> Any ideas/suggestions?
> I am using Jackrabbit 2.1.1 WAR deployed on websphere and API calls are
> being made through RMI. Contents are stored in Oracle database.
> My threads are not sharing sessions, each thread makes a call to to
> load/fetch/modify function and session is created and logged out in those
> functions.
> I am not using any explicit locking (except that I had to put session.save()
> in synchronized block amoung all threads, since all threads were blocked
> without that synchronized block, as mentioned earlier).
> Please help.
> Thanks.
> KS
> -- 
> View this message in context: http://jackrabbit.510166.n4.nabble.com/Jackrabbit-performance-in-multi-threaded-environment-tp3034980p3036201.html
> Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.

View raw message