Return-Path: Delivered-To: apmail-jackrabbit-dev-archive@www.apache.org Received: (qmail 45474 invoked from network); 3 Nov 2008 13:12:06 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 3 Nov 2008 13:12:06 -0000 Received: (qmail 37536 invoked by uid 500); 3 Nov 2008 13:12:12 -0000 Delivered-To: apmail-jackrabbit-dev-archive@jackrabbit.apache.org Received: (qmail 37153 invoked by uid 500); 3 Nov 2008 13:12:11 -0000 Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@jackrabbit.apache.org Delivered-To: mailing list dev@jackrabbit.apache.org Received: (qmail 37137 invoked by uid 99); 3 Nov 2008 13:12:11 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 03 Nov 2008 05:12:11 -0800 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.140] (HELO brutus.apache.org) (140.211.11.140) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 03 Nov 2008 13:11:03 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 7B53B234C264 for ; Mon, 3 Nov 2008 05:11:44 -0800 (PST) Message-ID: <1975118352.1225717904504.JavaMail.jira@brutus> Date: Mon, 3 Nov 2008 05:11:44 -0800 (PST) From: "Jukka Zitting (JIRA)" To: dev@jackrabbit.apache.org Subject: [jira] Resolved: (JCR-631) Change resources sequence during transaction commit. In-Reply-To: <12157786.1163160462374.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/JCR-631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting resolved JCR-631. ------------------------------- Resolution: Duplicate Assignee: Jukka Zitting Resolving as a duplicate of JCR-1775 where I fixed this and other ordering issues with versioning. > Change resources sequence during transaction commit. > ---------------------------------------------------- > > Key: JCR-631 > URL: https://issues.apache.org/jira/browse/JCR-631 > Project: Jackrabbit > Issue Type: Improvement > Affects Versions: 0.9, 1.0, 1.0.1, 1.1 > Reporter: Przemo Pakulski > Assignee: Jukka Zitting > > It seems that during commmit of transaction first changes in version storage are committed, followed by workspace changes. > If second transaction fail it leads to situation where some nodes in workspace could have reference (base version for example) to nonexistenst version in version storage. In such case this node is corrupted, cannot be checked in anymore :-(. > Long term solution is make versioning operation fully transactional (see JCR-630). In short term I think it is worth to change sequence of commit operations on different resources to stores changes in version storage before workspace changes. > It would be better to have some redundant data in version storage (not referenced version) than broken reference in workspace I think. > Any comments ? Does it make sense ? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.