Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Message-ID: <18872428.1166089522506.JavaMail.jira@brutus>
Date: Thu, 14 Dec 2006 01:45:22 -0800 (PST)
From: "Przemo Pakulski (JIRA)" <jira@apache.org>
To: dev@jackrabbit.apache.org
Subject: [jira] Commented: (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

    [ http://issues.apache.org/jira/browse/JCR-631?page=comments#action_12458405 ] 
            
Przemo Pakulski commented on JCR-631:
-------------------------------------

I simply tried to reaarange order of commits by swapping stateMgr and versionMgr in txResources array (XASessionImpl class) :

        txResources = new InternalXAResource[] {
            ((XAWorkspace) wsp).getXAResourceBegin(),
            stateMgr, lockMgr, versionMgr,
            ((XAWorkspace) wsp).getXAResourceEnd()
        };

But, after this change some tests using transactions fails (there is low level failure when tests trying to cleanup testroot node).
Is there any evident reason why this sequence couldn't be changed ?

> Change resources sequence during transaction commit.
> ----------------------------------------------------
>
>                 Key: JCR-631
>                 URL: http://issues.apache.org/jira/browse/JCR-631
>             Project: Jackrabbit
>          Issue Type: Improvement
>    Affects Versions: 1.0, 1.0.1, 1.1, 0.9
>            Reporter: Przemo Pakulski
>
> 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.
-
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