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 <[email protected]> To: [email protected] 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 <[email protected]> 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
