Can I assume this is a bug and file a JIRA? Seems like rather big problem to me.
2010/3/8 Dan Diephouse <[email protected]> > My impression was that as long as you do not have same name siblings, > concurrent additions are allowed: > > > http://n4.nabble.com/Problem-in-Multithreaded-Environment-tp516406p516415.html > > 2010/3/8 Alexander Klimetschek <[email protected]> > > On Mon, Mar 8, 2010 at 13:18, Dan Diephouse >> <[email protected]> wrote: >> > I'm having some problems doing concurrent addition of nodes to a parent >> node >> > in Jackrabbit. I'm probably doing something stupid and I'm wondering if >> > someone can comment on what that might be. >> > >> > I've attached a simple test which starts up a bunch of threads which add >> > nodes to a parent node concurrently. If I add in locks I can get this to >> > work, but I shouldn't have to use locks IIUC. However, the test always >> fails >> > with this: >> > >> > javax.jcr.InvalidItemStateException: Item cannot be saved because it has >> > been modified externally: node /testParent >> >> This exception is to be expected. JCR does not define a guarantee on >> what concurrent operations an implementation can successfully merge. >> Locks are present in JCR as a general mechanism for such >> synchronizations. >> >> I believe that this specific case (adding nodes) was improved in 2.0, >> but I couldn't find a jira issue. Could someone confirm or deny? >> >> Regards, >> Alex >> >> -- >> Alexander Klimetschek >> [email protected] >> > > > > -- > Dan Diephouse > http://mulesource.com | http://netzooid.com/blog > -- Dan Diephouse http://mulesource.com | http://netzooid.com/blog
