How to handle the concurrency problems on ASP.Net Database

<数据唯一性>

ACID中重要的一个环节: Data Isolation

Data Isolation
Creating fully-isolated transactions in a multithreaded environment is a non-trivial exercise. There are three ways isolation can be violated:

Lost update: one thread reads a record, a second thread updates the record, and then the first thread overwrites the second thread's update.
线程1读了一条记录，线程2更新了一条记录，接着线程1覆盖了线程2的更新。

Dirty read: thread one writes data; thread two reads what thread one wrote. Thread one then overwrites the data, thus leaving thread two with old data.
线程1写入了数据，线程2读取了线程1所写入的数据。线程1更改了数据，最后线程2读取的是没有更新的旧数据。

Unrepeatable read: thread one reads data; the data is then overwritten by thread two. Thread one tries to re-read the data but it has changed.
线程1读去了数据；但是此数据接着被线程2修改了。线程1试图从新读取数据，但是数据已经被修改了。

Solution for Multiuser Updates:

To prevent this kind of problem, you may use any of the following strategies:

step1: Locking the records. When one user is working with a record, other users can read the records but they cannot update them. 锁定要修改的记录。
App: You would need to write monitoring processes that keep track of how long records have been locked, and unlock records after a time-out period.

step2:Updating only the columns you change. In the previous example, QA would have changed only the owner and the status, while the developer would have changed only the description.
只更新你要修改的列.
App: Comparing Original Against New，This method involves creating an event handler for the RowUpdating event. The event handler examines the original value of each field and queries the database for the value currently in the database.

step3:Previewing whether the database has changed before you make your updates. If so, notify the user. 预先检查一下在执行更新之前数据库是否已经被修改了，如果是这样的话，通知用户。

step4:Attempting the change and handling the error, if any.
处理更改和错误。
App: The best approach to managing concurrency is to try the update and then respond to errors as they arise.This approach has tremendous efficiency advantages.For this approach to work, your stored procedure for updates must fail if the data has changed in the database since the time you retrieved the dataset. Since the dataset can tell you the original values that it received from the database, you need pass only those values back into the stored procedure as parameters, and then add them to the Where clause in your Update statement,