jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Boston <...@tfd.co.uk>
Subject Re: relentless InvalidItemStateException
Date Tue, 19 Oct 2010 10:33:32 GMT
Thanks, it was concurrent modification of the same Item ( I feel a bit stupid for not seeing
it earlier).
When I say "removed synchronization" I didn't delete the synchronized wrappers, I ensured
that the SystemSession was not shared between threads (by binding a SystemSession instance
to each thread) an ensured that the EventListener.onEvent methods did not use a SystemSession,
rather put a list of interesting events into a concurrent queue to be processed next time
the owning thread does some work.

I had a look at applying JCR-2699 which looks like it will remove some of the lower level
blocking but unfortunately the patches between 2.1.1 and HEAD are too great for us to use.
We are 2 weeks past our release date. I think we will have to wait till 2.2 comes out for


On 19 Oct 2010, at 10:17, Jukka Zitting wrote:

> Hi,
> On Tue, Oct 19, 2010 at 10:44 AM, Ian Boston <ieb@tfd.co.uk> wrote:
>> Any ideas ?
> We've typically seen such problems in cases where a client application
> has been using the same session from multiple concurrent threads,
> which is why we eventually decided to implement explicit
> synchronization of session access in JCR-890.
> I'm not sure if this is the cause of the problem also in your case,
> but it seems likely given your note about removed synchronization
> code. That code is there in Jackrabbit for a purpose and while such
> syncronizations can and should be removed (see for example the work on
> JCR-2699), doing so requires a pretty careful examination of potential
> unwanted side-effects. It would be great if you could file your
> changes as tightly scoped patches in Jira so we could better review
> them and perhaps point out potential problems.
> BR,
> Jukka Zitting

View raw message