## LOCK-Anweisung (lock_statement)

Die LOCK-Anweisung (lock_statement) ordnet Objekten der aktuellen Transaktion eine Sperre zu.

### 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> ::= ROW <table_name> KEY <key_spec>,...
| ROW <table_name> CURRENT OF <result_table_name>

### Erläuterung

Die angegebene Tabelle darf keine temporäre Basistabelle, keine View-Tabelle und kein Synonym sein. Wenn der Tabellenname eine View-Tabelle identifiziert, werden Sperren auf die Basistabellen gesetzt, die der View-Tabelle zugrundeliegen.

#### (WAIT)/(NOWAIT)

● Wenn (NOWAIT) spezifiziert wird, wird nicht auf die Freigabe einer Sperre durch eine andere Transaktion gewartet, sondern im Fall einer Sperrkollision ein Fehler gemeldet. Wenn keine Kollision vorliegt, wird die gewünschte Sperre gesetzt.

● Wenn keine WAIT-Option oder (WAIT) angegeben ist, wird bei einer Sperrkollision auf die Freigabe von Sperren maximal so lange gewartet, wie der spezielle Datenbankparameter REQUEST_TIMEOUT angibt.

#### <lock_spec>

##### TABLE <table_name>,...

Bei Angabe von TABLE <table_name>,... wird eine Sperre für die genannte Tabelle angelegt.

Wenn der Tabellenname eine nicht änderbare View-Tabelle identifiziert, ist nur das Setzen einer Lesesperre für diese View-Tabelle möglich. Als Folge dieser SQL-Anweisung sind anschließend für alle Basistabellen die der View-Tabelle zugrundeliegen Lesesperren gesetzt.

##### <row_spec> ...

Bei Angabe von <row_spec> ... wird eine Sperre für die durch die Schlüsselwerte oder durch einen Standpunkt in einer Ergebnistabelle bezeichnete Zeile einer Tabelle angelegt.

Die Angabe einer row_spec erfordert, dass die angegebene Tabelle eine Schlüsselspalte besitzt, d. h. falls durch den Tabellennamen eine View-Tabelle angegeben ist, muss diese änderbar sein.

Bei Tabellen, die ohne Schlüsselspalten definiert wurden, kann die implizit existierende Schlüsselspalte SYSKEY CHAR(8) BYTE in einer Schlüsselspezifikation key_spec verwendet werden.

Wenn CURRENT OF <result_table_name> angegeben wird, muss die Ergebnistabelle mit FOR UPDATE spezifiziert worden sein.

#### SHARE

SHARE definiert eine Lesesperre für die aufgeführten Objekte. Zum Setzen von Lesesperren muss der aktuelle Benutzer das SELECT-Privileg besitzen.

#### EXCLUSIVE

EXCLUSIVE definiert eine Schreibsperre für die aufgeführten Objekte. Zum Setzen von Schreibsperren muss der aktuelle Benutzer das UPDATE-, DELETE- oder INSERT-Privileg besitzen.

#### OPTIMISTIC

OPTIMISTIC definiert eine optimistische Sperre auf Zeilen. Diese ist nur in Zusammenhang mit den Isolation-Leveln 0, 1, 10 und 15 sinnvoll.

#### Weitere Informationen

##### Deadlock

Wenn das Datenbanksystem einen durch Sperren verursachten Deadlock erkennt, dann wird die Transaktion durch ein implizites ROLLBACK WORK beendet.

##### Reproduzierbarkeit

Werden für das Lesen von Zeilen mittels einer SELECT-Anweisung reproduzierbare Ergebnisse gewünscht, müssen die gelesenen Objekte gesperrt werden, und die Sperren müssen bis zur Reproduktion gehalten werden. Für die Reproduzierbarkeit ist es im allgemeinen erforderlich, die betroffenen Tabellen explizit mittels eines oder mehrerer LOCK-Anweisungen oder implizit durch Verwendung des Isolation-Level 3 lesend zu sperren. Dadurch wird gewährleistet, dass kein anderer Benutzer die Tabelle ändern kann.

Siehe auch:

LOCK-Option (lock_option)

UNLOCK-Anweisung (unlock_statement)

Konzepte des Datenbanksystems, Sperren für Datenbankobjekte