LOCK statement 

The LOCK statement assigns a lock to the current transaction (see transactions).

Syntax

<lock_statement> ::=
LOCK [(WAIT) | (NOWAIT)] <lock_spec> IN SHARE MODE
LOCK [(WAIT) | (NOWAIT)] <lock_spec> IN EXCLUSIVE MODE
LOCK [(WAIT) | (NOWAIT)] <lock_spec> IN SHARE MODE <lock_spec> IN EXCLUSIVE MODE
LOCK [(WAIT) | (NOWAIT)] <row_spec>... OPTIMISTIC

<lock_spec> ::= TABLE <table_name>,... | <row_spec>...
| TABLE <table_name>,... <row_spec>...

row_spec, table_name

Explanation

The specified table cannot be a base table, a view table (see table), nor a synonym. If the table name identifies a view table, locks are set on the base tables on which the view table is based. To set SHARE locks, the current user must have the SELECT privilege; to set EXCLUSIVE locks, the user requires the UPDATE, DELETE or INSERT privilege.

<row_spec>...

A <row_spec>... creates a lock for the table row denoted by the key values or a position in a result table.

Specifying a row_spec requires that the specified table have a key column; that is, if the table name identifies a view table, this must be modifiable.

TABLE <table_name>,...

If TABLE <table_name>,... is specified, a lock is created for the table in question.

If the view table identified by the table name is not updateable, only a SHARE lock can be set. As a result of this SQL statement, all base tables underlying the view table are subsequently locked in SHARE mode.

SHARE

SHARE defines a SHARE lock for the listed objects. If a SHARE lock is set, no concurrent transaction can modify the locked objects.

EXCLUSIVE

EXCLUSIVE defines an exclusive lock for the listed objects. If an exclusive lock is set, no concurrent transaction can modify the locked objects. Concurrent transactions can only read-access the locked objects in isolation level 0.

Exclusive locks for rows that have not been modified yet can be released using the UNLOCK statement before the transaction ends.

OPTIMISTIC

OPTIMISTIC defines an optimistic lock on rows. This lock only makes sense when it is used together with the isolation levels 0, 1, 10, and 15. An update operation of the current user on a row which has been locked by this user using an optimistic lock is only performed if this row has not been updated in the meantime by a concurrent transaction. If this row has been changed in the meantime by a concurrent transaction, the update operation of the current user is rejected. The optimistic lock is released in both cases. If the update operation was successful, an exclusive lock is set for this row. If the update operation was not successful, it should be repeated after reading the row again with or without optimistic lock. In isolation level 0, an explicit lock must be specified for the new read operation. In this way, it can be ensured that the update is done to the current state and that no modifications made in the meantime are lost.

The request of an optimistic lock only collides with an exclusive lock. Concurrent transactions do not collide with an optimistic lock.

See also:

Transactions

Locks can be requested either implicitly or explicitly. Explicit lock requests are made with the LOCK statement. Whether a lock is requested implicitly and how long it remains assigned to the transaction depends on the isolation level specification in the CONNECT statement.

SHARE locks and exclusive locks set on single table rows which have not yet been updated can be released within a transaction. Exclusive locks on updated table rows or table locks cannot be released within a transaction.

The locks assigned to a transaction by the LOCK statement are usually released when the transaction ends provided that the COMMIT statements or the ROLLBACK statements that end a transaction do not contain a LOCK statement.

WAIT/NOWAIT

If the database system has to wait too long for locks to be released when setting explicit or implicit locks, it issues a return code to this effect. The user can then respond to this return code, e.g., by terminating the transaction. In this case, the database system does not execute an implicit ROLLBACK WORK.

Deadlock

Whenever the database system recognizes a deadlock caused by explicit or implicit locks, it ends the transaction with an implicit ROLLBACK WORK.

Reproducibility

If reproducible results are needed to read rows using a select statement, the read objects must be locked and the locks must be kept until reproduction. Reproducibility usually requires that the tables concerned are locked in SHARE mode, either explicitly using one or more lock statements or implicitly by using the isolation level 3. This ensures that other users cannot modify the table. To ensure the reproducibility of the SQL statement SELECT DIRECT, it is sufficient to implicitly or explicitly lock the row to be read in SHARE mode.

Number of locks

The fewer objects locked, the more transactions can operate simultaneously on the database without colliding with lock requests of other transactions. For this reason, unnecessary locks should be avoided and locks that have been set should be released as soon as possible.

If a transaction explicitly or implicitly requests too many row locks (SHARE or exclusive locks) on a table, the database system tries to obtain a table lock instead. If this causes collisions with other locks, the database system continues to request row locks. This means that table locks are obtained without waiting periods. The limit beyond which the system attempts to transform row locks into table locks depends on the installation parameter MAXLOCKS.