Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@jackrabbit.apache.org
Received-SPF: pass (athena.apache.org: domain of stefko.ivanov@gmail.com
 designates 72.14.220.159 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=GkIUcmHdBzxEU1t95A9KKQwWMpJXYc8t1qMic2BKOGgHeO7+0HGMKTezQU+3MBavW+VmXVn2u9djUXZjIcYqO2HxO9VkKW9v6XVJC0eQSC9pL5WJUENOSlLDtZQBBagq6W4C2y2JrEjUZg+hhhpTJPfxccvSed09JASmvqBUk7I=
Message-ID: <eda76b7a0801131541u6528d415tee60901f4aa80366@mail.gmail.com>
Date: Mon, 14 Jan 2008 00:41:07 +0100
From: "Stefan Ivanov" <stefko.ivanov@gmail.com>
To: users@jackrabbit.apache.org
Subject: Re: Problem in Multithreaded Environment
In-Reply-To: <47892EF1.5070208@mulesource.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_7180_25985827.1200267667479"
References: <47892E85.8020201@mulesource.com>
 <47892EF1.5070208@mulesource.com>

------=_Part_7180_25985827.1200267667479
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi Dan

I have the same problem. I tried this with Local and XA Transaction Manager
but still ... :-(
I use 1.3.3 and at the moment I'm happier with the Local Transaction
Manager.

I've done different things to avoid this: reorganization of the data
structure tree, unique node names but the problem is still here.

Stefan


2008/1/12, Dan Diephouse <dan.diephouse@mulesource.com>:
>
> Dan Diephouse wrote:
> > Heya, I think I'm probably doing something pretty stupid here, but I'm
> > having a few problems using Jackrabbit in a multithreaded environment.
> > If you can imagine I have this scenario:
> >
> > Thread #1 running inside my unit test which is doing stuff to the
> > repository all in one session.
> > Thread #2 which is reading stuff inside the repository and updating
> > some nodes
> >
> > I think occasionally these threads collide though and start modifying
> > the same node. Then I starting getting things like:
> >
> > javax.jcr.RepositoryException: failed to create transient state:
> > there's already a property state instance with id
> > 1d038015-6c48-4654-a685-1dcf57a6bf6f/{
> http://www.jcp.org/jcr/1.0}mixinTypes:
> > there's already a property state instance with id
> > 1d038015-6c48-4654-a685-1dcf57a6bf6f/{
> http://www.jcp.org/jcr/1.0}mixinTypes
> >
> >    at
> > org.apache.jackrabbit.core.PropertyImpl.getOrCreateTransientItemState(
> PropertyImpl.java:97)
> >
> >    at
> > org.apache.jackrabbit.core.PropertyImpl.restoreTransient(
> PropertyImpl.java:143)
> >
> >    at
> > org.apache.jackrabbit.core.ItemImpl.restoreTransientItems(ItemImpl.java
> :734)
> >
> >    at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1233)
> >    at org.apache.jackrabbit.core.SessionImpl.save(SessionImpl.java:849)
> > ...
> > Caused by: org.apache.jackrabbit.core.state.ItemStateException:
> > there's already a property state instance with id
> > 1d038015-6c48-4654-a685-1dcf57a6bf6f/{
> http://www.jcp.org/jcr/1.0}mixinTypes
> >
> >    at
> >
> org.apache.jackrabbit.core.state.SessionItemStateManager.createTransientPropertyState
> (SessionItemStateManager.java:629)
> >
> >    at
> > org.apache.jackrabbit.core.PropertyImpl.getOrCreateTransientItemState(
> PropertyImpl.java:90)
> >
> >    ... 42 more
> >
> > Or:
> >
> > javax.jcr.RepositoryException: failed to create transient state:
> > there's already a property state instance with id
> > 1d038015-6c48-4654-a685-1dcf57a6bf6f/{http://www.jcp.org/jcr/1.0}uuid:
> > there's already a property state instance with id
> > 1d038015-6c48-4654-a685-1dcf57a6bf6f/{http://www.jcp.org/jcr/1.0}uuid
> >    at
> > org.apache.jackrabbit.core.PropertyImpl.getOrCreateTransientItemState(
> PropertyImpl.java:97)
> >
> >    at
> > org.apache.jackrabbit.core.PropertyImpl.restoreTransient(
> PropertyImpl.java:143)
> >
> >    at
> > org.apache.jackrabbit.core.ItemImpl.restoreTransientItems(ItemImpl.java
> :734)
> >
> >    at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1233)
> >    at org.apache.jackrabbit.core.SessionImpl.save(SessionImpl.java:849)
> > ....
> > Caused by: org.apache.jackrabbit.core.state.ItemStateException:
> > there's already a property state instance with id
> > 1d038015-6c48-4654-a685-1dcf57a6bf6f/{http://www.jcp.org/jcr/1.0}uuid
> >    at
> >
> org.apache.jackrabbit.core.state.SessionItemStateManager.createTransientPropertyState
> (SessionItemStateManager.java:629)
> >
> >    at
> > org.apache.jackrabbit.core.PropertyImpl.getOrCreateTransientItemState(
> PropertyImpl.java:90)
> >
> >    ... 42 more
> >
> > If the second thread was accessing a node created by the first thread
> > and the node wasn't saved yet, would that explain these errors?
> >
> > Any ideas how to avoid this???
> >
>
> One other thing. Those exceptions are from thread #2. I get this
> exception from thread #1:
>
> org.springframework.dao.ConcurrencyFailureException: Invalid item state;
> nested exception is javax.jcr.InvalidItemStateException: /activities:
> the node cannot be saved because it has been modified externally.
>
> Caused by: javax.jcr.InvalidItemStateException: /activities: the node
> cannot be saved because it has been modified externally.
>    at org.apache.jackrabbit.core.NodeImpl.makePersistent(NodeImpl.java
> :969)
>    at
> org.apache.jackrabbit.core.ItemImpl.persistTransientItems(ItemImpl.java
> :687)
>    at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1198)
>    at org.apache.jackrabbit.core.SessionImpl.save(SessionImpl.java:849)
>
> Cheers,
> - Dan
>
> --
> Dan Diephouse
> MuleSource
> http://mulesource.com | http://netzooid.com/blog
>
>

------=_Part_7180_25985827.1200267667479--