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.
this is IMO a rather theoretical problem. i am not aware of any jcr client code
which actually does re-try a failed save operation after having
partially discarded
and fixed transient changes by calling Item.refresh(false);
however, i agree that, theroretically, it is an issue ;)
In don't think so. Consider two users concurrently working on the same
web page. The user who saves last and runs into a conflict loses *all*
his work. No way to merge, partially apply or keep it otherwise. His
only option is to discard all of his work and to do it again from start.
Michael
Possible solutions:
1) The Microkernel makes as much effort as possible to three way merge
changes.
+1, agreed.
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.
i don't think we need that because IMO there's no real world use case.
cheers
stefan
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
