Locking during updates

The database server modifies the information contained in a particular record using the following procedure. As with insertions, this sequence of operations is followed for all transactions regardless of their isolation level.

  1. Acquire a shared schema lock on the table, if one is not already held.
  2. Acquire an intent-to-write table lock on the table, if one is not already held.
    1. Identify candidate rows to be updated. As rows are scanned, they are locked. The default locking behavior is described in Isolation levels and consistency.

      At isolation levels 2 and 3 the following differences occur that are different from the default locking behavior: intent-to-write row-level locks are acquired instead of read locks, and intent-to-write locks may in some cases be acquired on rows that are ultimately rejected as candidates for update.

    2. For each candidate row identified in step 2.a, follow the rest of the sequence.
  3. Write lock the affected row.
  4. Update each of the affected column values as per the UPDATE statement.
  5. If indexed values were changed, add new index entries. The original index entries for the row remain, but are marked as deleted. New index entries for the new values are inserted while a short-term insert lock is held. The server verifies index uniqueness where appropriate.
  6. If any foreign key values in the row were altered, acquire a shared schema lock on the primary table(s) and follow the procedure for inserting new foreign key values as outlined in Locking during inserts. Similarly, follow the procedure for WAIT_FOR_COMMIT if applicable.
  7. If the table is a primary table in a referential integrity relationship, and the relationship's UPDATE action is not RESTRICT, determine the affected row(s) in the foreign table(s) by first acquiring a shared schema lock on the table(s), an intent-to-write table lock on each, and acquire write locks on all of the affected rows, modifying each as appropriate. Note that this process may cascade through a nested hierarchy of referential integrity constraints.

After the last step, any AFTER UPDATE triggers may fire. Upon COMMIT, the server verifies referential integrity by ensuring that the number of orphans produced by this transaction is 0, and release all locks.

Modifying a column value can necessitate a large number of operations. The amount of work that the database server needs to do is much less if the column being modified is not part of a primary or foreign key. It is lower still if it is not contained in an index, either explicitly or implicitly because the column has been declared as unique.

The operation of verifying referential integrity during an UPDATE operation is no less simple than when the verification is performed during an INSERT. In fact, when you change the value of a primary key, you may create orphans. When you insert the replacement value, the database server must check for orphans once more.

Copyright © 2008, iAnywhere Solutions, Inc. - SQL Anywhere 11.0.0