[
https://issues.apache.org/jira/browse/OAK-464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13534950#comment-13534950
]
Michael Dürig commented on OAK-464:
-----------------------------------
bq. I thought reading the journal is only required if oak-core created a branch
that the MicroKernel couldn't merge due to a conflict?
Currently reading the journal is only required if the branch doesn't contain
any changes. We could change this to try a merge first and only if that fails
do the rebase. However, this is currently blocked by OAK-496.
bq. As far as I know, this will not actually increase the memory requirement
compared to implementing it in the MicroKernel, because the MicroKernel would
need to do basically the same.
Yes but the Microkernel wouldn't need to call {{getJournal()}} which causes all
changes to be encoded into a string (this is the additional memory I'm
referring to). It could instead just rely on the internal representation of the
changes.
bq. What would be the JCR API method calls needed that would cause a session to
do that?
Assume a session sets property {{foo}} to 42. On commit it detects a conflict
since in the meanwhile someone else also set a property with the same name. The
sessions decides to revert its local changes by doing {{^foo:null}}. No that
sessions change log looks like this: {{ ^/foo:42 ^/foo:null}}. The first
operation will still conflict thus in essence making any conflict resolution
impossible.
bq. Isn't the JCR method supposed to fail if there is/was a conflicting update?
Yes. But the user of that session should be able to resolve conflicts manually
and then retry. This doesn't work in this approach. See above bullet point.
> RootImpl.rebase() doesn't handle move operations correctly
> ----------------------------------------------------------
>
> Key: OAK-464
> URL: https://issues.apache.org/jira/browse/OAK-464
> Project: Jackrabbit Oak
> Issue Type: Bug
> Reporter: Michael Dürig
>
> Doing {{RootImpl.rebase()}} causes moves to be changed to remove followed by
> add. Which causes moves of large sub trees to become very expensive.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
