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 Tired of [EMAIL PROTECTED]@! come-ons? Let our SpamGuard
protect you. http://uk.docs.yahoo.com/nowyoucan.html
