jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shaun Barriball" <sbarr...@yahoo.co.uk>
Subject RE: Profiling shows Session management to be a hotspot - session pooling etc
Date Fri, 30 Mar 2007 07:30:22 GMT
Thanks for the response Brian.
We're using Spring to setup the Sessions for both the Editor and Reader but
we're not currently associating it with a transaction.
So by your comment "ensure everything that modifies the repository happens
transactionally" is it best to:

 * ensure the "Editor" app associates every update operation in a
transaction to ensure atomicity etc (ACID)

 * ensure the "Reader" app associates the session with a transaction for the
duration of a request which should guarantee a consistent view on JCR and
avoid the InvalidItemStateException otherwise known as the "carpet being
pulled from under you".

So I'm presuming the exception is due to the non-ACID way in which we're
using the repos?


-----Original Message-----
From: Brian Thompson [mailto:elephantium@gmail.com] 
Sent: 29 March 2007 17:29
To: users@jackrabbit.apache.org
Subject: Re: Profiling shows Session management to be a hotspot - session
pooling etc

You might wrap methods that use the shared session in a try-catch block.  If
that exception gets thrown, acquire a new session and retry the action.

You'll need to ensure that everything that modifies the repository happens
transactionally, but this might be a solution.


On 3/29/07, Shaun Barriball <sbarriba@yahoo.co.uk> wrote:
> Hi all,
> Yesterday we modified our 'view' web application to use a shared 
> global Session rather than Session per request pattern based on 
> (appreciated) feedback from the list. The result was a large increase 
> in performance but we are now seeing the following exception thrown
> Caused by: javax.jcr.InvalidItemStateException:
> 5f3e21de-2ba9-43bf-b096-1d80cc406efa/{
> http://www.acme.co.uk/xmlns/contentmod
> el}styleClass: the item does not exist anym ore
>         at
> org.apache.jackrabbit.core.ItemImpl.sanityCheck(ItemImpl.java:157)
>         at
> org.apache.jackrabbit.core.PropertyImpl.getName(PropertyImpl.java:1154
> )
> .....which implies that the session is getting out of date with 
> changes made by the 'editor' web application. We're using a mdoel 2 
> deployment.
> Is there anything we could be doing wrong in our code for this to 
> occur or is using a shared session a not viable?
> Regards,
> Shaun.
> -----Original Message-----
> From: Jukka Zitting [mailto:jukka.zitting@gmail.com]
> Sent: 27 March 2007 14:45
> To: users@jackrabbit.apache.org
> Subject: Re: Profiling shows Session management to be a hotspot - 
> session pooling etc
> Hi,
> On 3/27/07, David Nuescheler <david.nuescheler@gmail.com> wrote:
> > the only issue that i am aware of with respect to concurrent read 
> > operations on a shared session is during shutdown under certain 
> > special
> conditions.
> > generally an application should be able to concurrently read from 
> > the same session
> Note that while this is currently true in Jackrabbit, it might not be 
> true in some other JCR implementation or in a future Jackrabbit 
> release. We might for example want to introduce some session-level 
> read cache that would not be thread-safe.
> I would recommend using a thread pool instead of accessing a single 
> session from multiple threads.
> BR,
> Jukka Zitting

All new Yahoo! Mail "The new Interface is stunning in its simplicity and ease of use." - PC

View raw message