Return-Path: 
 <users-return-10430-apmail-jackrabbit-users-archive=jackrabbit.apache.org@jackrabbit.apache.org>
Delivered-To: apmail-jackrabbit-users-archive@minotaur.apache.org
Received: (qmail 29695 invoked from network); 29 Jan 2009 21:46:03 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 29 Jan 2009 21:46:03 -0000
Received: (qmail 54293 invoked by uid 500); 29 Jan 2009 21:45:58 -0000
Delivered-To: apmail-jackrabbit-users-archive@jackrabbit.apache.org
Received: (qmail 54284 invoked by uid 500); 29 Jan 2009 21:45:58 -0000
Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:users-help@jackrabbit.apache.org>
List-Unsubscribe: <mailto:users-unsubscribe@jackrabbit.apache.org>
List-Post: <mailto:users@jackrabbit.apache.org>
List-Id: <users.jackrabbit.apache.org>
Reply-To: users@jackrabbit.apache.org
Delivered-To: mailing list users@jackrabbit.apache.org
Received: (qmail 54273 invoked by uid 99); 29 Jan 2009 21:45:58 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 29 Jan 2009 13:45:58 -0800
X-ASF-Spam-Status: No, hits=-0.0 required=10.0
	tests=SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: domain of mkwhitacre@gmail.com
 designates 209.85.200.173 as permitted sender)
Received: from [209.85.200.173] (HELO wf-out-1314.google.com) (209.85.200.173)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 29 Jan 2009 21:45:50 +0000
Received: by wf-out-1314.google.com with SMTP id 26so137733wfd.13
        for <users@jackrabbit.apache.org>;
 Thu, 29 Jan 2009 13:45:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:mime-version:received:date:message-id:subject
         :from:to:content-type:content-transfer-encoding;
        bh=MUkgl9kBApqnbT4pUMNrcISON805TRa/bYDW42FSPFw=;
        b=dRiOw0G/+6mw7cT7u0U3+Qd8lTQmjTdzj6TNCafI+EX8IXDXypkFtUVBEwv0FxmPoF
         QPMn7dxRfBh45Pzu4Az8hnHbE+daWaf2d0xN4II8Drbmj/op1Dd7Im1apGtTPIO4VNw7
         xwiSUZqlYb17uD5bD6y/as5ovKxcx+Pg4a27g=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:date:message-id:subject:from:to:content-type
         :content-transfer-encoding;
        b=neI+nXOTlimxyJ4UC7Pc0O22wmoc1VDS64EoiX1vnA4X0OInoV+IgReljIWPDTNU9B
         XScQJy6+xt1A6ZNYvkNit0AStB6TVot79dILJo0naCxhbPi6msweMzkRhRSPuAX5ZhsJ
         kGpP/0huEyrYsInQdleDfJ++AGkVD575mD6dY=
MIME-Version: 1.0
Received: by 10.142.170.6 with SMTP id s6mr167473wfe.58.1233265530238;
 Thu, 29
	Jan 2009 13:45:30 -0800 (PST)
Date: Thu, 29 Jan 2009 15:45:30 -0600
Message-ID: <ad7356600901291345n7d20bde7r513dd0e4b522d3a8@mail.gmail.com>
Subject: Are Repository objects thread safe?
From: Micah Whitacre <mkwhitacre@gmail.com>
To: users@jackrabbit.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked by ClamAV on apache.org

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
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