jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brian Thompson" <elephant...@gmail.com>
Subject Re: Profiling shows Session management to be a hotspot - session pooling etc
Date Thu, 29 Mar 2007 16:29:29 GMT
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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message