[
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.
