On Wed, Jan 25, 2012 at 6:04 PM, Michael Dürig <mdue...@apache.org> 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.
please note that Item.refresh() will most likely be deprecated in JCR 2.1. > > 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 ;) > > 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
