BTW: the current microkernel prototype doesn't consider concurrent
removal of a specific node a conflict, i.e. it already implements the
proposed behavior.
Hmm no?
String head = mk.getHeadRevision();
head = mk.commit("/", "+\"qoo\":{}", head, "");
String r1 = mk.commit("/", "-\"qoo\"", head, "");
String r2 = mk.commit("/", "-\"qoo\"", head, "");
The commit for r2 gives me an error:
org.apache.jackrabbit.mk.api.MicroKernelException:
org.apache.jackrabbit.mk.store.NotFoundException: /qoo
Michael
cheers
stefan
Regards,
Thomas
On 1/25/12 6:04 PM, "Michael Dürig"<[email protected]> wrote:
Hi,
In an earlier discussion (probably offline), we decided to not implement
Item.refresh() since it doesn't go well with the MVCC model jr3 is based
on. Furthermore, JCR doesn't have an Item.undo() method for undoing
changes.
This may lead to problems when a Session.save() fails due to the
underlying Microkernel.commit failing because it detected a conflict.
Now there might be some transient changes (like deletions) which can't
be selectively undone by the user. So the user is left with a transient
space containing his changes but he can only discard them as a whole.
Not very satisfactory.
Possible solutions:
1) The Microkernel makes as much effort as possible to three way merge
changes.
2) The user needs to do a session refresh with keep changes = true and
save again.
3) Introduce a Item.undo method on the JCR API.
1) Mitigates the problem such that it only occurs rarely.
2) Is really nothing more than moving the problem of the failed commit
due to a conflict from the Microkernel to the transient space: now the
transient space needs to do conflict resolution.
3) Is what I think we should do. This enable the user to resolve his
conflicts selectively.
Michael
