All About Locking

BACKGROUND

Locking strategy is the methodology used to handle multi-user issues. How one handles the fact that 2 people want to update the same record at the same time can be performed in one of three ways.

DO NOTHING

  • User 1 reads a record
  • User 2 reads the same record
  • User 1 updates that record
  • User 2 updates the same record

User 2 has now over-written the changes that User 1 made. They are completely gone, as if they never happened. This is called a lost update.

PESSIMISTIC LOCKING

Lock the record when it is read.

  • User 1 reads a record and locks it by putting an exclusive lock on the record ( FOR UPDATE clause)
  • User 2 attempts to read and lock the same record, but must now wait behind User 1
  • User 1 updates the record (and, of course, commits)
  • User 2 can now read the record with the changes that User 1 made
  • User 2 updates the record complete with the changes from User 1

The lost update problem is solved. The problem with this approach is concurrency. User 1 is locking a record that they might not ever update. User 2 cannot even read the record because they want an exclusive lock when reading as well. This approach requires far too much exclusive locking, and the locks live far too long (often across user control - an absolute no-no). This approach is almost never implemented.

OPTIMISTIC LOCKING

Optimistic locking does not use exclusive locks when reading. Instead, a check is made during the update to make sure that the record has not been changed since it was read. This can be done by checking every field in the table.
i.e. UPDATE table1 SET col2 = 'x' WHERE col1=:oldcol1 AND col2=:oldcol AND col3=:oldcol3 AND…

There are, of course, several disadvantages to this. First, one must have already SELECT'ed every single column from the table. Secondly, one must build and execute this massive statement. Most people implement this, instead, through a single column, usually called TIMESTAMP. This column is used for no other purpose than implementing optimistic concurrency. It can be a NUMBER or a DATE. The idea is that it is given a value when the row is inserted. Whenever the record is read, the TIMESTAMP column is read as well. When an update is performed, the TIMESTAMP column is checked. If it has the same value at UPDATE time as it did when it was read, then all is well, the UPDATE is performed and the TIMESTAMP is changed!. If the TIMESTAMP value is different at UPDATE time, then an error is returned to the user - they must re-read the record, re-make their changes, and try to update the record again.

  • User 1 reads the record, including the TIMESTAMP of 21
  • User 2 reads the record, including the TIMESTAMP of 21
  • User 1 attempts to update the record. The TIMESTAMP in hand (21) matches the timestamp in the database (21), so the update is performed and the TIMESTAMP is updated to 22.
  • User 2 attempts to update the record. The TIMESTAMP in hand (21) does not match the TIMESTAMP in the database (22), so an error is returned. User 2 must now re-read the record, including the new TIMESTAMP of 22 and User 1's changes, re-apply their changes and re-attempt the update.
© copyright 2001-2014 ABCdba.com | all rights reserved