Question

I have an application with the architecture like client/server/db. Communication between client and server is WCF (has been migrated from asmx) and database is SQL Server 2005.

The project has a requirement, that you cannot update an order, which have been changed (updated) by another user after your initial read. A common requirement in most applications I think.

An update of an order is usually as:

1. Client read an order – an initially-read copy is stored (Session) on the server
2. Client updates order – returns updated-order to server
3. Server will read order again from database and compare with initially-read to check, if order has been changed by another user – in case client will be notified to re-read order
4. Server will save changes

This way to handle data change has the effect, that at a certaint point (3), the server will have 3 (different) copies of the order in memory! Anyone knows another strategy for this?

We are running WCF with AspNetBackwardCompability, because we need the Session-variable to “hold” the initially-read copies – it will make my day, if we could dump that

Answer 1

One solution is to have the client supply both the initially-read values and the updated values when saving. Then you don’t need a copy of the original values in session.

DataSets have the built-in capability to store both versions (DataRowVersion.Original and DataRowVersion.Current), but you’ll have to provide your own method to do this (e.g. an operationContract:

SaveMyData(MyType original, MyType updated);

You can then save to the database thus:

UPDATE MyTable
SET Col1 = @NewCol1, Col2 = @NewCol2, ...
WHERE Col1 = @OldCol1, Col2 = @OldCol2, ...
IF @@ROWCOUNT = 0 ... update failed ...

Alternatively you can have a TIMESTAMP / ROWVERSION column in your table. You roundtrip this to the client, and test it when updating:

UPDATE MyTable
SET Col1 = @NewCol1, Col2 = @NewCol2, ...
WHERE PKCol = @PK AND TimeStampCol = @OldTimeStamp
IF @@ROWCOUNT = 0 ... update failed ...

You are of course relying on the client to correctly return the original values / original timestamp when saving. But this isn’t a security issue – a malicious client can’t do any more damage than it could with your session-based solution.