Community
Participate
Working Groups
There is no possibility to resolve a single dirty CDOObject with the state CONFLICT by "updating" it from the server. Consider the following use case: a) Two clients have made modifications on the same CDOObject. b) Client A saves (transaction.commit()). c) Client B gets notified by a CDOSessionInvalidationEvent and indicates in its viewer that the object now has a conflict (red, bold font). d) The user of client B selects the conflicting object in the viewer and invokes a resolve conflict action from the context menu. e) The resolve conflict action updates the selected CDOObject (with state CONFLICT) from the server. See also "[CDO] Resolve single CDOObject in state CONFLICT" (http://www.eclipse.org/newsportal/article.php?id=37841&group=eclipse.tools.emf#37841)
About your comments: Bjoern Sundin wrote: > Exactly! Though, for me I would rather see it as view.rollbackAndUpdate(object): rollback local changes and retrieve latest version. First.. what I meant was more for the view completely .. not only one object. Also the method name should be call. view.rollbackAndUpdateAndModify(void); // :-) TO do it for one object is complicated.. since many others changes could occured at the same time..( e.g.: a.getElements().add(b); // Could result in many modifications of the graphs. Simon
Simon, I didn't want to knowbest regarding names in any way. Sorry if you felt offended. I'll leave the naming to others. :-) I guess it is a tricky matter to find a general way to handle it on one single object. In the case of a changed attribute it would probably be fairly simple. In the example with a list not... Maybe also not for a chain of changes (since I don't have any OperationHistory in my app). I'm not so into the mechanics under the surface of CDO, but would it be possible to have something that just resolves the conflic objects of the view, then? I mean leaving local non conflicting changes intact and updating/merging the rest. Would that impact the consistency of the model? Bjoern
Committed initial solution to HEAD.
/** * A strategy used to customize the default conflict resolution behaviour of {@link CDOTransaction transactions}. * * @see CDOTransaction.Options#setConflictResolver(CDOConflictResolver) * @author Eike Stepper * @since 2.0 */ public interface CDOConflictResolver { public static final CDOConflictResolver NOOP = new CDOConflictResolver() { public void resolveConflicts(CDOTransaction transaction, Set<CDOObject> conflicts) { // Do nothing } }; /** * Resolves conflicts after remote invalidations arrived for objects that are locally dirty or detached. * <p> * The implementor might want to use API in {@link CDOConflictUtil}. * <p> * <b>Important:</b> Those conflicts that are resolved by the implementation of this method <b>must</b> be removed * from the passed set of conflicts! */ public void resolveConflicts(CDOTransaction transaction, Set<CDOObject> conflicts); }
Created attachment 120411 [details] Patch v1 - incomplete 3 test cases in InvalidationTest are failing.
I will work on it a little bit!
Committed to HEAD. I fixed failing testcases. We had 3 testcases failing all the time.. + another one that was failing once in a while... TO fix the first 3 failed testcases, I added the following (passiveUpdate) private void handleCommitNotification(final long timeStamp, Set<CDOIDAndVersion> dirtyOIDs, final Collection<CDOID> detachedObjects, final Collection<CDORevisionDelta> deltas, InternalCDOView excludedView, final boolean passiveUpdate, boolean async) I override passiveUpdate since when we refresh a session... it override the passiveUpdate settings. To fix the others testcases, I had to change the testcase itself since changesubscription is now async... We still need to make sure handleCOnflicts happens after invalidation and changesubscription notifications. Simon
(In reply to comment #7) > We still need to make sure handleCOnflicts happens after invalidation and > changesubscription notifications. Done.
Hand-over ;-)
What's the state of this?
(In reply to comment #10) > What's the state of this? > After the initial push we did, we didn't improve it.
Rebasing all unresolved enhancement requests to 3.0
Rebasing all outstanding enhancements requests to version 4.0
Conflict resolution should now be done with the new CDOConflictResolvers like CDOMergingConflictResolver. Please reopen if you think that's not adequate.
