Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@jackrabbit.apache.org
Received-SPF: pass (herse.apache.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.co.uk;
  h=Received:X-YMail-OSG:From:To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-MimeOLE:Thread-Index:In-Reply-To;
  b=tELok8sl2iEtTJYr0NDNrHHRyG1viMH5QOnGg3bpyZbUOiDLkyrc20nFLqgyUgjht9Odo8J3uC9rzXaMaCMJKEYoYEAAiV4XUUAiSfOG2dqhIUCdN1u0Ehy/Njus61H3z9tiRY2gpaKxpfUW7rTZyNvUe1jmrCg5lG1DrxqgpGs=
  ;
From: "Shaun Barriball" <sbarriba@yahoo.co.uk>
To: <users@jackrabbit.apache.org>
Subject: RE: Profiling shows Session management to be a hotspot - session
 pooling etc
Date: Fri, 30 Mar 2007 08:30:22 +0100
Message-ID: <013a01c7729d$475b0d90$7201a8c0@mobileiq.local>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcdyH3s1Zg+schucRq+fiqP84R15xwAfMn3g
In-Reply-To: <7d3e1a010703290929n4382df6cv6117922aa4df3ae8@mail.gmail.com>

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?

Regards,
Shaun.


-----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.

-Brian


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
periodically:
>
> 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 Magazine 
http://uk.docs.yahoo.com/nowyoucan.html