You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by Andrey Adamovich <an...@yahoo.com> on 2009/10/26 09:56:28 UTC
Handling of InvalidItemStateException
Hi guys!
We are now expriencing a number of InvalidItemStateException in our web application caused by 2 or more users updating the same content. As far as I understood it is in design of JR to throw InvalidItemStateExcpetion in such situation and that's ok, but I wanted to ask about the common way to handle that. We are fairly ok that the last processed change wins the update. So far we have come up with the following code:
repeat = false;
do {
try {
// Do node update/remove
} catch (InvalidItemStateException e) {
repeat = true;
}
} while (repeat)
Is this a common pattern how to handle that? Or is it a better way to avoid such situations?
Best regards,
Andrey Adamovich
Re: Handling of InvalidItemStateException
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Tue, Oct 27, 2009 at 10:43 AM, Andrey Adamovich
<an...@yahoo.com> wrote:
> 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.
OK, thanks for the info. It might be good to have this as a bug
report, especially if you can provide some more details about your
deployment setup and the types of operations that your application is
performing. I don't have any direct ideas what could be the cause of
the problem, but perhaps we'll come up with something later.
> 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?
The main benefit of using JCR locks is that it'll protect your content
also from clients that don't participate in your custom locking
scheme. If that's not an issue in your case, then there is not much
difference. I personally think that the programming model of JCR locks
is not very developer-friendly, so using a custom solution or a
utility tool like the Locked class in jackrabbit-jcr-commons is
probably an easier approach.
BR,
Jukka Zitting
Re: Handling of InvalidItemStateException
Posted by Andrey Adamovich <an...@yahoo.com>.
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 <ju...@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
<an...@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
Re: Handling of InvalidItemStateException
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Mon, Oct 26, 2009 at 11:17 AM, Andrey Adamovich
<an...@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
Re: Handling of InvalidItemStateException
Posted by Andrey Adamovich <an...@yahoo.com>.
Thanks for your reply, Jukka
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? Possible suspects from my side:
1) JTA transaction times out while changes are performed. I'm not quite sure though if this affects any state of JR.
2) Journaling somehow affects states (as journaling is outside our update code we cann't apply our own locking scheme to that and thus getting conflicts).
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).
What would be your advice in this case? Thanks in advance.
Best regards,
Andrey Adamovich
________________________________
From: Jukka Zitting <ju...@gmail.com>
To: users@jackrabbit.apache.org
Sent: Monday, 26 October, 2009 10:56:08
Subject: Re: Handling of InvalidItemStateException
Hi,
On Mon, Oct 26, 2009 at 9:56 AM, Andrey Adamovich
<an...@yahoo.com> wrote:
> Is this a common pattern how to handle that? Or is it a better way to avoid such situations?
You said you are fine with the last change "winning". Then why can't
you simply ignore the InvalidItemStateException? It's caused by two
concurrent changes colliding, so you could just as well treat the
winning change as the last one. This strategy is typically only
appropriate when the changes being made are simple property updates,
etc.
The other approach is to use locking to explicitly synchronize such
competing changes. This strategy is best suited for more complex
changes.
BR,
Jukka Zitting
Re: Handling of InvalidItemStateException
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Mon, Oct 26, 2009 at 9:56 AM, Andrey Adamovich
<an...@yahoo.com> wrote:
> Is this a common pattern how to handle that? Or is it a better way to avoid such situations?
You said you are fine with the last change "winning". Then why can't
you simply ignore the InvalidItemStateException? It's caused by two
concurrent changes colliding, so you could just as well treat the
winning change as the last one. This strategy is typically only
appropriate when the changes being made are simple property updates,
etc.
The other approach is to use locking to explicitly synchronize such
competing changes. This strategy is best suited for more complex
changes.
BR,
Jukka Zitting