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 Mon, 26 Oct 2009 10:17:51 GMT
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 <jukka.zitting@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
<andrey.adamovich@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



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