PostgreSQL LOCK (Sperre)

Sperren werden hauptsächlich verwendet, um die Konsistenz der Datenbankdaten aufrechtzuerhalten. Sie können verhindern, dass Benutzer eine Zeile oder die gesamte Tabelle ändern, und werden im Allgemeinen in Datenbanken mit hoher Nebenläufigkeit verwendet.

Wenn mehrere Benutzer auf die Datenbank zugreifen und gleichzeitige Operationen nicht kontrolliert werden, können falsche Daten gelesen und gespeichert werden, wodurch die Konsistenz der Datenbank zerstört wird.

In einer Datenbank gibt es zwei grundlegende Sperrtypen: exklusive Sperren und gemeinsame Sperren.

Wenn eine exklusive Sperre für ein Datenobjekt gesetzt wird, können andere Transaktionen es weder lesen noch ändern.

Wenn eine gemeinsame Sperre gesetzt wird, kann das Datenbankobjekt von anderen Transaktionen gelesen, aber nicht geändert werden.

Syntax des LOCK-Befehls

Die grundlegende Syntax des LOCK-Befehls lautet wie folgt:

LOCK [ TABLE ]
name
 IN
lock_mode

• name: Der Name (optional schemaqualifiziert) einer vorhandenen Tabelle, die gesperrt werden soll. Wenn ONLY vor dem Tabellennamen angegeben wird, wird nur diese Tabelle gesperrt. Wenn ONLY nicht angegeben wird, werden die Tabelle und alle ihre untergeordneten Tabellen (falls vorhanden) gesperrt.
• lock_mode: Der Sperrmodus gibt an, mit welchen Sperren diese Sperre in Konflikt steht. Wenn kein Sperrmodus angegeben wird, wird der restriktivste Modus, ACCESS EXCLUSIVE, verwendet. Mögliche Werte sind: ACCESS SHARE, ROW SHARE, ROW EXCLUSIVE, SHARE UPDATE EXCLUSIVE, SHARE, SHARE ROW EXCLUSIVE, EXCLUSIVE, ACCESS EXCLUSIVE.

Sobald eine Sperre erworben wurde, wird sie für den Rest der aktuellen Transaktion gehalten. Es gibt keinen UNLOCK TABLE-Befehl; Sperren werden immer am Ende der Transaktion freigegeben.

Deadlock

Ein Deadlock kann auftreten, wenn zwei Transaktionen darauf warten, dass die jeweils andere ihre Operationen abschließt. Obwohl PostgreSQL sie erkennen und mit einem Rollback beenden kann, sind Deadlocks immer noch sehr unpraktisch. Um zu verhindern, dass Ihre Anwendung auf dieses Problem stößt, stellen Sie sicher, dass die Anwendung so entworfen ist, dass Objekte in derselben Reihenfolge gesperrt werden.

Advisory-Sperren

PostgreSQL bietet Methoden zum Erstellen von Sperren mit anwendungsdefinierter Bedeutung. Diese werden Advisory-Sperren genannt. Da das System ihre Verwendung nicht erzwingt, liegt die korrekte Verwendung bei der Anwendung. Advisory-Sperren sind nützlich für Sperrstrategien, die nicht zum MVCC-Modell passen.

Beispielsweise ist eine häufige Verwendung von Advisory-Sperren die Simulation der pessimistischen Sperrstrategie, die für sogenannte „Flat-File“-Datenverwaltungssysteme typisch ist. Obwohl Flags, die in einer Tabelle gespeichert sind, für denselben Zweck verwendet werden können, sind Advisory-Sperren schneller, vermeiden Tabellenaufblähung und werden am Ende einer Sitzung automatisch vom Server bereinigt.

Beispiele

Erstellen Sie die Tabelle COMPANY (Laden Sie die COMPANY-SQL-Datei herunter) mit den folgenden Daten:

exampledb# select * from COMPANY;
 id | name  | age | address   | salary
----+-------+-----+-----------+--------
  1 | Paul  |  32 | California|  20000
  2 | Allen |  25 | Texas     |  15000
  3 | Teddy |  23 | Norway    |  20000
  4 | Mark  |  25 | Rich-Mond |  65000
  5 | David |  27 | Texas     |  85000
  6 | Kim   |  22 | South-Hall|  45000
  7 | James |  24 | Houston   |  10000
(7 rows)

Das folgende Beispiel sperrt die Tabelle COMPANY in der Datenbank exampledb im Modus ACCESS EXCLUSIVE.

Die Anweisung LOCK funktioniert nur im Transaktionsmodus.

exampledb=#BEGIN;
LOCK TABLE company1 IN ACCESS EXCLUSIVE MODE;

Der obige Vorgang liefert das folgende Ergebnis:

LOCK TABLE

Die obige Meldung gibt an, dass die Tabelle bis zum Ende der Transaktion gesperrt ist, und um die Transaktion abzuschließen, müssen Sie die Transaktion zurückrollen oder festschreiben.

Weitere Erweiterungen