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