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:[EMAIL PROTECTED] Sent: 29 March 2007 17:29 To: [email protected] 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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] > Sent: 27 March 2007 14:45 > To: [email protected] > Subject: Re: Profiling shows Session management to be a hotspot - > session pooling etc > > Hi, > > On 3/27/07, David Nuescheler <[EMAIL PROTECTED]> 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
