On Thu, Jan 29, 2009 at 11:40 PM, Alessandro Bologna <[email protected]> wrote: > I am not sure if this relate to the issue you are having, but I believe (and > I may be wrong) that altough you are using separate sessions and create > unique node names,if they share the parent you may have an issue there since > the parent is the one that has its state changing when you add or remove a > node.
you're absolutely right. > > I know that, to some extent, JR merges the changes silently, but in some > cases it can't. I remember there was an open JIRA issue about that, you may > want to check in there. here's the issue: http://issues.apache.org/jira/browse/JCR-584 cheers stefan > > Alessandro > > > > On Thu, Jan 29, 2009 at 4:45 PM, Micah Whitacre <[email protected]>wrote: > >> I've read in other mailing list posts that Session objects are not >> thread safe however I was curious if Repository (specifically >> RepositoryImpl) is a threadsafe object. I'm trying to do some >> concurrency testing for my code which is built on top of >> JCR/Jackrabbit and was seeing some exceptions and wanted to insure I >> didn't miss something simple like misusing an object. >> >> The use case I'm testing with is in a single java 1.5 jvm using >> jackrabbit-core 1.4.6 configured to hit a local derby database, I'm >> simulating multiple threads trying to add a child node to the same >> parent. So the pseudo code for each thread is the following: >> >> session = Repository.login() >> parentNode = session.getNode(); >> parentNode.checkout() <--this node is versioned >> try{ >> childNode = parentNode.addNode(<unique name>) >> childNode.addMixin(versionable) >> childNode.checkout >> childNode.setProperty(...) >> parentNode.setProperty(...) <-- sets a custom author property >> parentNode.save() >> childNode.checkin() >> }finally{ >> parentNode.checkin() >> } >> >> There is only one RepositoryImpl object created in the JVM, so that >> object is being shared across threads. When this code executes I see >> InvalidItemStateExceptions because of messages like: >> >> javax.jcr.InvalidItemStateException: >> 8de5ca79-0207-4567-9627-c9184b739933/{http://www.foo.com/jcr/1.0}author<http://www.foo.com/jcr/1.0%7Dauthor> >> has been modified externally >> at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1251) >> >> Occasionally the message will also indicate it couldn't store >> "predecessors" because of being modified externally since the parent >> node is versioned. If the exception is thrown then I will also get an >> InvalidItemStateException thrown when trying to checkin the parent >> node because it has pending changes. I will also sometimes get the >> InvalidItemStateException thrown when trying to checkout the parent >> node with a message that the "isCheckedOut" property was modified >> externally. >> >> So the first question is this use case valid or am I violating the JCR >> contract and using an object in an improper manner (e.g. should the >> repository instance not be used across threads)? Is there a >> proper/recommended way to handle concurrent modification of the same >> node? >> >> Also I'm curious, if there is only one repository instance, do I have >> to retrieve the node again to make sure it is up to date or is calling >> node.refresh(true) sufficient for me to do node.save() without getting >> the InvalidItemStateException. >> >> Thanks for your help, >> Micah >> >
