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 <[email protected]>: > > 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 d...@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 <[email protected]>: >>> 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 >>> >>> > >
