How to handle the concurrency problems on ASP.net Database

asp.net
< data uniqueness >

An important part of 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 "the" the "the" the "the" D thread ' s update.
Thread 1 reads a record, thread 2 updates a record, and thread 1 overwrites the update of thread 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.
Thread 1 writes the data, and thread 2 reads the data written by thread 1. Thread 1 changed the data, and the last thread 2 read old data that was not updated. 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.
Thread 1 reads the data, but the data is then modified by thread 2. Thread 1 tried to read the data again, but the data has been modified.

Solution for multiuser Updates:

To prevent this kind of problem, with the following strategies:
Step1:locking the records. When one of the user is working with a and the other users can read the records but they cannot update them. Lock the record you want to modify.
App:you would need to write monitoring processes this keep track of how long records have been locked, and unlock records After a time-out period.step2:Updating only the columns your change. In the previous example, QA would have changed to the owner and the status while the developer would have The description.
Update only the columns you want to modify.
App:comparing Original against New,this method involves a event creating for the handler event. The event handler examines the original value of each field and queries the database for the value currently in the Databa SE. step3:previewing whether the database has changed before you to make your updates. If So, notify the user. Check to see if the database has been modified before the update is performed, and if so, notify the user. Step4:attempting the "change" and handling the error, if any.
Handle changes and errors.
App:the best approach to managing concurrency are to try the update and then respond to errors as they. 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 T IME you retrieved the dataset. Since the dataset can tell you the original values which it received from the database, and you need pass only those values BAC K into the stored procedure as parameters, and then add them to the Where clause in your Update statement,