Return-Path: Delivered-To: apmail-incubator-jackrabbit-dev-archive@www.apache.org Received: (qmail 22096 invoked from network); 30 Jun 2005 14:18:32 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 30 Jun 2005 14:18:32 -0000 Received: (qmail 92095 invoked by uid 500); 30 Jun 2005 14:18:23 -0000 Mailing-List: contact jackrabbit-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: jackrabbit-dev@incubator.apache.org Delivered-To: mailing list jackrabbit-dev@incubator.apache.org Received: (qmail 91963 invoked by uid 99); 30 Jun 2005 14:18:19 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received: from [192.87.106.226] (HELO ajax.apache.org) (192.87.106.226) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 30 Jun 2005 07:18:19 -0700 Received: from ajax.apache.org (ajax.apache.org [127.0.0.1]) by ajax.apache.org (Postfix) with ESMTP id DBFA2CA for ; Thu, 30 Jun 2005 16:18:15 +0200 (CEST) Message-ID: <1413475956.1120141095898.JavaMail.jira@ajax.apache.org> Date: Thu, 30 Jun 2005 16:18:15 +0200 (CEST) From: "Jukka Zitting (JIRA)" To: jackrabbit-dev@incubator.apache.org Subject: [jira] Updated: (JCR-18) Multithreading issue with versioning In-Reply-To: <754032452.1100122223788.JavaMail.apache@nagoya> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N [ http://issues.apache.org/jira/browse/JCR-18?page=all ] Jukka Zitting updated JCR-18: ----------------------------- Fix Version: 1.0 Description: 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. was: 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. > Multithreading issue with versioning > ------------------------------------ > > Key: JCR-18 > URL: http://issues.apache.org/jira/browse/JCR-18 > Project: Jackrabbit > Type: Bug > Components: versioning > Environment: Jackrabbit SVN Rev. 56918 > Reporter: Felix Meschberger > Assignee: Tobias Strasser > Fix For: 1.0 > > 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://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira