jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrey Adamovich <andrey.adamov...@yahoo.com>
Subject Re: Handling of InvalidItemStateException
Date Tue, 27 Oct 2009 09:43:25 GMT
Hi Jukka!

Thank you very much for your reply.

Actually at the moment journaling is disabled and we still see those issues once in a while
(to be exact 97 out of about 350,000 node updates within 24 hours). But we just sometimes
encounter JTA timeout/roll back exceptions and InvalidItemStateExceptions are always somewhere
after those, but I can't prove from the logs the direct connection between those.

And we are not using JCR locks, but our own locking scheme with the help of ReentrantLocks.
I don't remember why we have avoided JCR locks, but do you think JCR native locks should be
better than custom (external to JCR) locking scheme?


Best regards,
Andrey Adamovich





________________________________
From: Jukka Zitting <jukka.zitting@gmail.com>
To: users@jackrabbit.apache.org
Sent: Monday, 26 October, 2009 15:48:41
Subject: Re: Handling of InvalidItemStateException

Hi,

On Mon, Oct 26, 2009 at 11:17 AM, Andrey Adamovich
<andrey.adamovich@yahoo.com> wrote:
> We have already tried using an additional locking scheme in order
> to avoid InvalidItemStateException, and it removed most of collisions
> actually, but it still seems to not always help, espiecially if there are
> more users assccing the system :(.
>
> Do you know of any other possible reasons?

Are you using session- or open-scoped locks? There's an old open issue
[1] about session-scoped locks not working across cluster nodes.

> The type of update where we usually get such exception is when a node has
> a number children, and one thread removes one child, and another thread
> adds another child, then there is a chance to get the InvalidItemStateException
> for the parent node at some point (and we do get that).

Automatic merging of such changes should already be supported since
Jackrabbit 1.2 [2]. Do you use same-name siblings? The merging code
from JCR-584 does not work if the child nodes all have the same name.

[1] https://issues.apache.org/jira/browse/JCR-1173
[2] https://issues.apache.org/jira/browse/JCR-584

BR,

Jukka Zitting



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