Change Tracking Structure

Question

We are looking to implement Optimistic locking in our WCF/WPF application. So far the best way I've come up with doing this is to implement a generic Optimistic which will store a copy of the original and any changes (so it will store two copies: the original and modified) of any value object that can be modified. Is this the best way of doing it?

For example: a UserVO will be wrapped by the generic as a Optimistic. When a change is made to the Optimistic, the change will be made to the modified copy stored in the Optimistic while the original also stored in the Optimistic will remain intact. The main issue seems to be that it will use up twice the space and hence bandwidth.

Thanks

EDIT The solution needs to be database independent, and it would be useful to be able to specify an conflict resolution policy per value object. (eg. A user object might try and merge if the updated rows weren't changed, but a transaction object would always require user intervention).

Answer 1

If you are using SQL server you can use a timestamp column. The timestamp column is changed anytime a row is modified. Essentially when your updating the DB you can check if the timestamp column is the same as when the client first got the data, if so no one has modified the data.

Edit

If you want to minimize the bandwidth, you could emulate the timestamp concept by adding a version number on each object. So for example:

1. Client 1 requests object, sever returns Object V1
2. Client 2 requests object, server returns Object v2
3. Client 1 modifies object sending it back to server as V1
4. Server compares the version and see's v1=v1 so it commits the change
5. Server increments the version of the object so now its v2
6. Client 2 modifis object sending it back to server as v1
7. Server compares the version and see's v1!=v2 so it performs whatever your policy is

For configuring your policy, you could define in a configuration a specific object that will handle Policy failures depending on the type of root object. You could whip up a IOptomisticCheckFailurePolicy interface, and you could probally use one of the DI libraries like structure map to create the object when you need it (Although you could just as easily load it up using reflection)

Answer 2

One way of implementing optimistic locking logic is to base it on a last modified timestamp of a row. So the update will look as follows:

UPDATE .... WHERE id = x AND last_updated = t

x: record id. t: the last updated timestamp of the row when it was loaded from the database (i.e. before modifications).

Note that one of the fields that must be updated directly or indirectly is the timestamp to be set to now (or UtcNow).

This way the update will fail in case the record was modified in the background. Once the update failed, you can issue further queries to detect the cause of the failure. For example,

1. Record has been deleted.
2. Record has been modified.

This simple approach provides row level optimistic locking, it is not column based and has no conflict resolution.

Answer 3

Have you looked at the Microsoft Sync Framework?