jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Abley" <james.ab...@gmail.com>
Subject Re: Liveness failures in DefaultISMLocking
Date Tue, 21 Oct 2008 22:21:23 GMT
2008/10/16 Marcel Reutegger <marcel.reutegger@gmx.net>:
> Hi,
> it seems that your application shares a session instance among multiple threads.
> while read-only access on a session instance from multiple threads is considered
> safe, write access is not. can you please check that your application uses a
> dedicated session when it writes to the repository?
> regards
>  marcel

Hi Marcel,

It's a good point. In our architecture we have 2 different applications:

* A (hopefully) high-throughput application that is responsible for
reading and rendering JCR items. This application can share a session
instance amongst threads. I'm not immediately familiar with the
reasons why we are pooling sessions in this manner, but I can find
out. As you say, this is considered safe (although I can't recall what
the JCR spec has to say about this).
* A separate content-authoring application that uses a single session
per client web session to talk to JCR.

I'm hopeful that the logging changes for an implementation of
ISMLocking based on DefaultISMLocking will provide more insight into
where our problem is. I'm not sure that we require XA for this
application, so I'm going to check on that and see whether we can
eliminate that from the source of potential issues.



View raw message