Mailing-List: contact jackrabbit-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jackrabbit-dev@incubator.apache.org
Message-ID: <26133058.1100184333014.JavaMail.apache@nagoya>
Date: Thu, 11 Nov 2004 06:45:33 -0800 (PST)
From: "Tobias Strasser (JIRA)" <jira@apache.org>
To: jackrabbit-dev@incubator.apache.org
Subject: [jira] Commented: (JCR-18) Multithreading issue with versioning
In-Reply-To: <754032452.1100122223788.JavaMail.apache@nagoya>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

     [ http://nagoya.apache.org/jira/browse/JCR-18?page=comments#action_55352 ]
     
Tobias Strasser commented on JCR-18:
------------------------------------

i must admit that i took no care about multihtreading until now. but of course i will do it now.

> Multithreading issue with versioning
> ------------------------------------
>
>          Key: JCR-18
>          URL: http://nagoya.apache.org/jira/browse/JCR-18
>      Project: Jackrabbit
>         Type: Bug
>  Environment: Jackrabbit SVN Rev. 56918
>     Reporter: Felix Meschberger
>     Assignee: Tobias Strasser

>
> In a multithreading environment with two or more threads accessing the same version history, inconsistent state may be encountered. Concretely, the first thread is currently checking in the node to which the version history is attached while the second thread walks this same version history by means of a "self-built" iterator, which just accesses the successors of each version to get the "next" to visit.
> At a certain point the second point may encounter an ItemNotFoundException with a stack trace similar to this:
> javax.jcr.ItemNotFoundException: c9bd405b-dff4-46ef-845c-d98e073e473a
>         at org.apache.jackrabbit.core.ItemManager.createItemInstance(ItemManager.java:354)
>         at org.apache.jackrabbit.core.ItemManager.getItem(ItemManager.java:230)
>         at org.apache.jackrabbit.core.SessionImpl.getNodeByUUID(SessionImpl.java:494)
>         at org.apache.jackrabbit.core.version.VersionImpl.getSuccessors(VersionImpl.java:86)
>         ....
> It seems that the first thread has already filled the successor of the version, while the node is not yet accessible by the createItemInstance method.
> This bug seems to not be enforcible, but it is easily reproducible.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira