On Thu, Jan 26, 2012 at 9:48 AM, Thomas Mueller <[email protected]> wrote: > Hi, > > I would try 1). I would not try 3) because the user wouldn't know which > item conflicted (well he could parse the message, but that would be > weird). Also, I would try to avoid a new API. > > For the case 'double delete' another solution is possible. > > * session1 deleted node /test and does some other changes > * session2 deleted node /test and does some other changes > * session1 save (successful) > * session2 save (fails: /test can't be deleted because it doesn't exist > any more) > > 4): The microkernel could ignore delete operations on paths that don't > currently exist. This is somewhat similar to what databases do: "delete > from test where id=1" will be successful if there is no row with id 1. Or > with JCR setProperty(..., null) for a non-existent property (which > currently works fine).
BTW: the current microkernel prototype doesn't consider concurrent removal of a specific node a conflict, i.e. it already implements the proposed behavior. 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 >
