3
Replies
Let's see... what do you mean by "lock the page?" That's generally not the approach that is taken in web-apps. Let me explain . . .
Any time that you allow more than one user to update records in a database at the same time, you must ensure that conflicting changes do not occur, such that one user's changes do not overwrite another's. There are two ways to do that: optimistic and pessimistic:
- The "pessimistic" approach is the one that you're describing: you "pessimistically" assume that two users will be updating the same record at the same time, so you "lock" the record to prevent that.
- The "optimistic" (or, "opportunistic") approach harbors warm, fuzzy feelings about human nature
and assumes that, in fact, out of however-many thousands of records, the odds are actually extremely small that any two users would in fact be updating exactly the same record at exactly the same time. It therefore allows the user to compose his changes, then checks to see if conflicting changes did occur right before updating the record. The record is locked only for a few milliseconds: "lock the record, check for conflict, post changes if no conflict occurred, unlock the record, then report back to the user." If a conflict is detected, the user must be informed and must resolve the issue.
Optimistic locking strategies are most often used in web applications because of the asynchronous nature of the HTTP protocol, as well as the need to support potentially thousands of users.
Probably the most common approach that is used for change-detection is a "change counter" field. It's a simple integer, and when you retrieve the record you remember what it is. Then, later, your SQL UPDATE statement looks something like this (assuming you "know" that the change-counter had the value 123456😞
UPDATE blahblah ...
SET ... blahblah ... , change_counter = change_counter + 1
WHERE ... blahblah AND ... change_counter = 123456
The statement will fail if the value of the change-counter isn't what you expected it to be, having updated none of the other fields.
Some applications also use a "lock field," which is a boolean field that can be True or False. Variations include a "lock timestamp," designed to automatically provide for lock-timeout when records are abandoned (a distinct possibility). Applications check this field upon retrieving the record and turn-away users from records that are now locked. But some mechanism must be provided to handle "stale locks," and the overhead of these mechanisms can be considerable.
Typically, it is necessary to use both a "lock field" and a "change counter" to prevent conflicts.
Do other mechanisms exist in the context of ColdFusion? Certainly yes. But memory considerations remain, as does the need to be able to periodically restart the web-server processes without thereby losing change-control information. Time and overhead are also an important issue: "optimism" is efficient while "pessimism" is costly.
I hope that was intended as humor.
The issue here, obviously, is when two people (unbeknownst to one another) are entering a record at the same time.
Both edits appear to "succeed," but one of them overwrites the other. Nobody knows.
Obviously this is an unacceptable situation, and this is precisely what the change-counter logic will successfully address. Both users upon beginning their edit-sessions capture the same change-counter value. When the first user makes his update, it succeeds and the counter is incremented. When the second user tries, it fails because the change-counter is not the same as it was.
"Indifference" has nothing to do with it: it's a serious bug that might not be detected in testing (if you actually do any) or if you only do this for a hobby in "casual" use.
AdChoices