Enhanced OptimisticConcurrenyException

Would you consider enhancing this exception by doing the following?

1. Add a freeform text OptimisticConcurrencyAction attribute for each property in the entity.
2. In the data property of the exception give a list of all properties changed with the above action atrribute, the original value and current value.  I'm assuming that the exception is thrown for only one entity at a time.  If not then the entity would need to be identified in the list.

This would allow the use of a more generic exception handler that could automatically resolve simple issues.  For instance, if function 1 didn't change any of the fields function 2 is trying to change, function 2 can simply refresh the entity, reapply the changes and continue the updating.  The Action attribute would allow indicating more advanced logic when function 2 updates a field updated by function 1.

I'm assuming it is possible to refresh an entity within the UOW.  If not, what would it take to make it so?

Thanks.

This sounds like a useful feature and I've logged a feature request for it.  It would be useful to have a bit more of an idea of how you see yourself using the OptimisticConcurrencyAction -- could you outline your thinking here?  Another idea that occurred to me while writing the feature request was that it might be nice to handle this via a Reconcile method or event, so that you could implement your logic at the entity level rather than in an exception handler around your SaveChanges call -- we would welcome feedback on that idea.

It's not currently possible to refresh an entity in the UOW, but we've had quite a few requests for it and will probably add it fairly soon.

I see two actions, at least initially.

• Replace - This means that a new property value is a complete replacement for the previous value.
• Delta - This means that a new property value represents an increase or decrease of the previous value.

An action could have a qualifying condition necessary to automatically apply the action. 

For example, say we have an inventory balance field.  We would give it a Delta actions with a condition of >=0.  Thus if we had an exception cause by function 1 getting some inventory, the condition wouldn't allow automaticaly applying the decrement by function 2 if that would take the inventory balance less than zero.

Another example might involve a sales order where it takes multiple people to pick the merchandise in the warehouse.  However, only one person can be picking an order at a time.  If we have a property showing who is currently picking the order then we could assign it a Replace action with the condition that the property must be blank before replacement.

A third example would be a variation of the Replace action where the precondition was actually another property rather than the one being changed.  If the property used to control picking above was really used by anyone working on the order, then a credit manager could be placing a credit hold when someone else is trying to pick the order.  Thus, two conditions would have to be met to change the user property:  the user property is blank and the hold code is blank.

Tthere would probably be other Actions that would evolve as we encounter new use cases, Hence the freeform text. 

As to Reconcile vs SaveChanges, I would prefer SaveChanges because I'll have to handle worse case issues there by abandoning the UOW and starting over.  I'd like to handle best case issues just before that and retry the SaveChanges.  I prefer to have all the different logic necessary to complete/abandon the update in the same block of code.

I just realized that I would also need the LockVersion of the database record.  I'd use this to control recursively attemping new updates.

Of course, none of this is possible without an Entity refresh.

Thanks for your consideration.