|Keep It Simple, Stupid|
Concurrency control in web applicationsby cbraga (Pilgrim)
|on Oct 24, 2003 at 16:19 UTC||Need Help??|
A problem which often arises when working with database applications is that of concurrency control, IOW, preventing race conditions such as the classic: you load a user's info page, someone else loads it, you change his name and save it, the other person changes his telephone and save it, losing the change you made.
"Traditional" two-tier applications which run the app logic and interface on the user's computer and use a database for storage had an easy way out: open a transaction when the user's record is opened and keep it locked for updates. However, in three and four tier web applications that is not feasible. A few alternatives arise:
— Keep track of records being edited with an "in use" field recording who's editing it. Problems arise in cases the editor goes away or waits too long to unlock.
— Add a version counter to each record, incremented in each update, and have your update fail (... AND vcounter=10 ...) if someone else changed it while you weren't looking. Simple and effective.
— Keep a change history in the form of a table containing records of all changes to all tables for a given time frame, and when a race condition is detected then reconcile the changes so that none's lost. Best approach, but requires a lot of work.
So, those are my ideas. Anyone got another approach?
P.S.: Saying that you should only update fields that actually changed, while a valid approach, doesn't count since it doesn't solve the problem. Two people could be updating a credit or stock total, for instance.