jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Guggisberg <stefan.guggisb...@gmail.com>
Subject Re: Are Repository objects thread safe?
Date Fri, 30 Jan 2009 10:01:18 GMT
On Thu, Jan 29, 2009 at 11:40 PM, Alessandro Bologna
<alessandro.bologna@gmail.com> 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 <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
>>
>

Mime
View raw message