Merge/Refresh Workspace: Question concerning conflict resolution

Question

hi!
thank's so far for answering our last question,now another question popped up during developing :)
we now have a state with our application where the user can select which objects to merge/refresh and finally commit these changes.
if there have been any conflicts he had to select a resolve operation for them. so far so good.
now, our method that performs the merging looks (no surprise) something like that: (the numbers are markers, used later on)
(1)
beginResolve();
do a few resolveConflicts();
(*) commit;
commitResolve();
(2)
(3)
do_merge/refresh_operations_of_death_in_correct_order();
(4)
ok, first question is concerning the line with the (*).
it seems we cannot call commitResolve() when there is an open transaction? as we run a spring managed application we first had it that way, that all of the above lines were executed within on transaction (that is, the complete merge/refresh operation going from (1) to (4)).
that didn't work, as we got exceptions on commitResolve(), that there is an open database transaction. is that because of the transaction wrapping the complete method? or did we do something else wrong?
now we split the method in two parts: one for the conflict resolution ((1) to (2) and one for the rest ((3) to (4)), both running within a transaction now. that works.
however, I feel a little bit unsafe with that, questions are:
if the first part runs in an own transaction and is commited: does the commitResolve() actually write data? or is that just something temporary on a per-session base? because, if something fails in the second part ((3) to (4)) then the transaction of that part of course rolls back fine, but the result of the conflict resolve part is probably still there? could we then, somewhere in the exception handling of the second transaction, call rollbackResolve()? or does it always have to happen within a conflict resolution session, that means, within (1) to (2)? the docs state the latter, but we're not really sure.
if something fails for whatever reason during the actual merge/refresh part, we need to make sure, that everything is rolled back to the state before
starting the whole process. it would be very dangerous to have some resolved conflicts hanging around that get merged/refreshed sometime later when the user doesn't even think about them.
btw, we also found the docs a bit inconsistent concerning conflict resolution. at some point it is explained, that after calling the resolveConflicts() a commit is needed, at another point this is left out and it is said, that one would just need to call commitResolve() afterwards and THEN a commit. it seems only the first explanation is correct (with another commit after the commitResolve()).
so, if you could clarify a bit on how a conflict resolution + merge/refresh session should look like concerning the management and scope of transactions, that would be really of great help and highly appreciated! the first tests worked fine with the way we have it working right now, but we always feel like there's a huge pitfall hiding somewhere ;)
best regards,
Andreas

Answer 1

Hi Ben,
after your explanation I agree. As the workspaces only carry the difference information of course there actually is no data in the child workspace if the object has been deleted in the parent.
I guess for the first we should not display this object to the user except when he's attempting to do a refresh, but not for a merge (or the other way round if the delete was done in the
child and NC in parent).
We didn't realize there is a rollbackTable with a WHERE clause, quite nice! Still, nothing practicable for us as we can't really know when a user might want to undo a delete and thus
which savepoint to use.
Reinserting would work, yes. We even tried that once for another scenario. Though in our case it would be important that the object also gets the same PK again, which is possible but still
feels like an ugly hack :-) Anyway, back to topic.
For the second scenario I was unfortunately mixing some WM and our users' terminology, thus it was not 100% clear. Sorry for that. What I meant was the following:
1) create new object in child
2) merge this object to parent
2a) DIFF is clear now, everything OK
3) goto parent workspace, new object is there
4) modify the new object there
5) goto child workspace again
6) open differences-viewer of our application <- here I wrote the users do a refresh, I meant they are >planning< to do a refresh, but not actually did it yet
OK, at point 6) we now get the diff information from the DIFF view and have an U for the parent and an I for the child. After your explanations and thinking over it some time we realized, that
this of course is totally correct: the last change in the parent was the update, the last change in the child the insert.
As the current version of our differences-viewer more or less displays the information from the DIFF-views in a straight way, the user now sees, that the object was updated in parent and new/inserted in child,
because those are the last operations for this row in both of the workspaces. That's what I meant is not intuitive, especially if they did not do all the operations themselves like in our small example and within
the timespan of 2 minutes.
It seems, we have to build some more abstraction around our current process?
To us it seems there are two solutions to this "problem", correct us if we oversee something:
1) currently synchronization within our application is directional, so either merge or refresh (except for conflict resolution, where the user might also want to decide to keep the object from the target workspace)
Thus we simply can ignore the DiffCode for the target workspace, except for conflicts, where we easily get the information from the CONF views
EDIT: no, we cannot simply ignore the target diffcode :( After some more thinking we have the same problem as with a real bidirectional synchronization process.
2) on the long run we actually planned to provide a bidirectional merge-tool to the user. In that case it's not that easy, as there is no single target workspace.
We didn't go into details yet, but probably we would need to retrieve further information, like e.g. the change timestamps for the DIFF rows for child and parent?
Then we could see what was actually the last change and display only that (except for U/U conflicts, but then again we get that information from the CONF view)
Any hints on how to do something like that the best way?
EDIT: We think it boils down to the question: how can we know, which parts of the DIFF have already been handled in a merge/refresh before and which haven't?
And another question, this time concerning the original topic: conflict resolution.
Is it possible in some way to ignore conflicts during a merge or refresh? Our users will definitely need that. The only idea we came up with yet would be again to use a savepoint (as you suggested
already concerning error rollback), that is have a savepoint (e.g. for the last time the workspace was synchronized) and then "fake resolve" the conflict (use CHILD with resolveconflicts) but do not
include the row in the following mergeTable() call. After merging has succeeded, use rollbackTable() for that row to the previous savepoint. Would that work?
Thanks again and regards,
Andreas Schilling
Edited by: aschilling on Dec 15, 2009 9:33 AM