Joe Rattz

In the DLINQ Overview for C# document, in the OCCR section, there is an Example 6 on page 67-68 (physical, not Word numbered).

In that example, there is a try/catch around the first SubmitChanges() call. In that catch, the code enumerates through the OptimisticConcurrencyException.Conflicts collection. The code then calls the Resolve() method on each Conflict. Then it enumerates through each Conflict's collection of OptimisticConcurrencyMemberConflict objects. If a member conflict object has the HaveModified flag set to false, it then calls the Resolve() method on that member conflict.

I have two questions.

1. What is the member conflict's Resolve method actually doing From what I can detect, it is doing nothing. You might want to say it is resolving each member conflict, but, don't forget, we already called the Resolve method on the OptimisticConcurrencyConflict object, which is one level up. In fact, to the best I can tell, you can comment out the call to the member conflict's Resolve method, and the code behaves exactly the same way. However, if you comment out the OptimisticConcurrencyConflict object's call to Resolve, and leave in the call to the member conflict's Resolve method, when SubmitChanges is called the second time, it still throws an OptimisticConcurrencyException. So apparently calling the member conflict's Resolve method alone does not resolve the conflict.

2. What is the member conflict's HaveModified property telling us Why only call the member conflict's Resolve method if the HaveModified property is false

Thanks.




Re: LINQ Project General What does OptimisticConcurrencyMemberConflict.Resolve() actually do?

Mathew Charles

1) OptimisticConcurrencyConflict.Resolve queries the database for the current database values for the object in conflict and updates the 'original state' in the change tracker. This step is what enables a subsequent Submit to succeed since it updates the values used in the OC check. It also modifies the current values based on the RefreshMode specified. OptimisticConcurrencyMemberConflict.Resolve just sets the current member value based on the mode or value specified. So if you want to do a member by member manual merge you need to call Resolve on the conflict first to update the internal tracked object, then you can set individual member values as needed. Note : there have been some API changes to OCCR that will be released in the February CTP. Among them, it is no longer necessary to call resolve on the conflict object before resolving each individual member conflict. The refresh of the internal tracked object state will happen implicitly when needed.

2) HaveModified returns true if the member has been modified by the user. In the example it is being used to effect a 'KeepChanges' manual merge - database values are being merged into the object without overwriting any of our changes.






Re: LINQ Project General What does OptimisticConcurrencyMemberConflict.Resolve() actually do?

Joe Rattz

Thanks for responding.

Something about your description doesn't seem quite right. If OptimisticConcurrencyConflict.Resolve modifies the current values as you say, and since you have to call OptimisticConcurrencyConflict.Resolve to update the original values to eliminate the conflict, what is the point of then calling OptimisticConcurrencyMemberConflict.Resolve to update the current values It was already done by the OptimisticConcurrencyConflict.Resolve. The only reason I can see is if you want to update some of the fields using a different RefreshMode than was provided when you called OptimisticConcurrencyConflict.Resolve. In this way, it seems like it could be an override at the field level from what you specified when calling OptimisticConcurrencyConflict.Resolve. But for that to make sense, I would think you would want to only do this logic (below) for some specific field, but the code is not filtering for a specific field.

Also, in that same example, the logic is:

if ( !mc.HaveModified)
//Resolve can take one of the values, or
//you can choose a RefreshMode option.
mc.Resolve(databaseVal);

Assume a conflict occurs on a field that the user has not modified. In this case, I'll use the ContactName, since in this example the user did not change it. We call SubmitChanges and since our current value doesn't match what's in the database, a conflict occurs. We then call OptimisticConcurrencyConflict.Resolve which updates the original value to what's in the database, and since we passed RefreshMode.KeepChanges, and because the user didn't modifiy it, the current value is set to the database value. So, since the user didn't modify it, it gets the database value. Then in the logic above, if the user hasn't modified it, it gets the value of the database, which is the same thing we just did. The logic above looks redundant to the call to OptimisticConcurrencyConflict.Resolve when a RefreshMode is passed as KeepChanges. This is kind of confusing, so am I saying something that is wrong

Thanks.






Re: LINQ Project General What does OptimisticConcurrencyMemberConflict.Resolve() actually do?

Matt Warren

Joe, you are correct. This logic is redundant and was an error in the documentation. There's no need to resolve individual members if you have already resolved the entire object.




Re: LINQ Project General What does OptimisticConcurrencyMemberConflict.Resolve() actually do?

Joe Rattz

Thanks for the info and the heads-up on the coming API changes!