Hi, 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. Ian On 10 Nov 2010, at 14:44, [email protected] 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.
