Re: javax.jcr.InvalidItemStateException: Item cannot be saved because it has been modified externally: node /

[Norman Maurer <no...@googlemail.com>]

Hi Ian,

thx for the details. So just one more question to get a better idea
about how to solve this. Is the problem the concurrent adding of nodes
via node.addNode(..) or the session.save() call ? So would it be
possible to call the addNode methods in concurrent and just
synchronize the session.save here ?


Thx,
Norman


2010/4/1 Ian Boston <ie...@tfd.co.uk>:
>
> On 1 Apr 2010, at 02:55, Norman Maurer wrote:
>
>> Hi Ian,
>>
>> I'm 100 % sure the session is not shared.
>>
>> About your (2).. I thought It should be no problem to add child nodes
>> in a multi-threading app if the name silbing of the childs are unique.
>> I'm wrong ?
>
> The problem here is deep under the covers child nodes are stored in an array that has to be re-written when updated. So if you add a child node the entire contents of the array is re-written, making it impossible to perform an optimistic merge of concurrent changes.
>
> You can concurrently modify individual child nodes, or separate properties, but you cant concurrently add multiple child nodes to a parent node. There is discussion on dev@jackrabbit about how JR3 will address this issue.
>
> Ian
>
> BTW, anyone, if I got that wrong, please correct, I dont want to spread misinformation by mistake.
>
>
>>
>> I will have a look at the code you posted later today..
>>
>>
>> Thx,
>> Norman
>>
>>
>> 2010/3/31 Ian Boston <ie...@tfd.co.uk>:
>>> There are a number of causes if its under heavy load:
>>>
>>> 1. Multiple threads (mistakenly) sharing the same session.
>>> 2. Multiple threads adding a child node the same parent node at exactly the same time, although this might also show up as a failure to merge a modification.
>>>
>>> If operating in a cluster you may find that events from modifications on other nodes result in the same problem as the state of the local shared cache changes in reaction to events from other nodes.
>>>
>>> One solution is to maintain an application level, in memory lock on the parent node to prevent concurrent modifications on the same parent node in JVM (although this doesn't solve the cluster problem). eg [1]
>>>
>>> A better strategy is to use a retry mechanism even propagating to the client with a suitable response code. (eg in http  409)
>>>
>>> Ian
>>>
>>> 1. http://github.com/ieb/open-experiments/blob/master/slingtests/osgikernel/bundles/locking/src/main/java/org/sakaiproject/nakamura/locking/LockManagerImpl.java
>>>
>>> On 30 Mar 2010, at 10:07, Norman Maurer wrote:
>>>
>>>> Hi all,
>>>>
>>>> I have an application which use many threads. Sometimes I see this
>>>> error on heavy load:
>>>>
>>>> javax.jcr.InvalidItemStateException: Item cannot be saved because it
>>>> has been modified externally: node /
>>>>
>>>> I wonder how this can happen because I don't add a Node directly to
>>>> the rootNode add this time..
>>>>
>>>> Is it maybe related to :
>>>> https://issues.apache.org/jira/browse/JCR-2428
>>>>
>>>> I'm using Jackrabbit 2.0.0 without transactions..
>>>>
>>>> Bye,
>>>> Norman
>>>
>>>
>
>

Re: javax.jcr.InvalidItemStateException: Item cannot be saved because it has been modified externally: node /

[smjain <ja...@gmail.com>]

Well I am facing the same issue and a little confused now.

We have multiple threads first adding a node to the parent node and then
adding some properties to the child 

node. I think doing it this way will hold the lock for the root node and
will serialize all access to the root node. 

I am thinking of saving the session after adding the child node to release
the lock for the root node. Adding 

properties to child nodes will aquire lock for individual child nodes and
should allow concurrent writes.

Do we also need to change the Locking Strategy to FineGrainedISMLocking to
allow concurrent writes still

The link somehow points to serialization of writes with DefaultLocking

http://jackrabbit.apache.org/concurrency-control.html

Please share your thoughts. I am stuck up here

Thanks
Shashank


-- 
View this message in context: http://jackrabbit.510166.n4.nabble.com/javax-jcr-InvalidItemStateException-Item-cannot-be-saved-because-it-has-been-modified-externally-nod-tp1744925p2301078.html
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.