![]() SQL database system |
Record lockingshsql has a built-in facility for record locking. shsql record locking is an advisory facility that allows database records to be reserved while changes are pending. It prevents other users from reserving or modifying records to which changes are pending. Record locking is recommended for any table that could be updated by more than one user or process concurrently. If used properly, record locking can alleviate some problems that are addressed by transaction control in full-blown DBMS systems.Successful use of record locking requires database accesses to be coded to detect attempts to access/update records that someone else has already locked. It is best if all programs that update a table that uses record locks be coded using the same conventions. Some procedural examples are given below. Developers should understand how record locking interacts with table locking, and be familiar with strategies for avoiding deadlock.
shsql's record locking facility is intended to be convenient and
easy to work with, with special consideration for web-based applications. The
SELECT .. FOR UPDATE
command is used to lock records.
Locked records are automatically unlocked upon the next
UPDATE or DELETE
executed by the same
user/identity
who locked the record. Record locks will also
automatically expire (time out) after a certain amount of time (30 minutes by default,
configurable).
This is useful in web-based applications where users can
lock records for editing but then aren't forced to follow through and save or cancel.
Here are the rules for using shsql record locking:
Example of record locking procedure - single record
Example of record locking procedure - multiple records
Operational detailsSELECT..FOR UPDATE locks a record by recording the current time and identity in the record's _locktime and _lockowner fields. UPDATE unlocks a record by setting the _locktime field to null (but the _lockowner field is left alone). A record is considered unlocked if the _locktime field is null or contains a time value that is old enough to be considered expired. Time values are stored using YMDhm notation. 0 - 9 are represented naturally; 10-35 are represented using characters a through z; 36-61 are represented using characters A through Z. The data returned by a SELECT..FOR UPDATE is retrieved immediately before the record lock is set; hence the returned _locktime and _lockowner fields are not current. Since setting record lock(s) involves updating the table, a table write lock is set to cover the duration of the update. A multi-row SELECT .. FOR UPDATE causes the table write lock to be in effect until all rows are fetched, so all rows should be retrieved without delay.
If someone attempts to UPDATE or DELETE a set of records without locking them
first, and the record set includes one or more records locked by others, the locked records
will not be affected but all other records in the target set will be. The UPDATE or
DELETE will return an error code of 7 to indicate that one or more target records was
locked and not modified. This can be avoided if all processes lock records
before UPDATING or DELETING them and, for multi-row updates where the record
locks could time out, re-issueing the SELECT ..FOR UPDATE just before update to
ensure that the records are still eligible for update (see multi-record example above).
|
![]() Copyright Steve Grubb |