jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alessandro Bologna <alessandro.bolo...@gmail.com>
Subject Re: Are Repository objects thread safe?
Date Thu, 29 Jan 2009 22:40:15 GMT
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

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.


On Thu, Jan 29, 2009 at 4:45 PM, Micah Whitacre <mkwhitacre@gmail.com>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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message