Eine Transaktion kann für eine Tabellenzeile (Datensatz) eine optimistische Sperre setzen. Das Datenbanksystem teilt der Transaktion die aktuelle Versionsnummer der Tabellenzeile mit.
Immer wenn die Tabellenzeile geändert wird, erhöht das Datenbanksystem die Versionsnummer. Durch einen Vergleich zwischen der ursprünglichen und der aktuellen Versionsnummer können Datenbankanwendungen ermitteln, ob die beim Setzen der Sperre gelesenen Daten noch aktuell sind oder neu eingelesen werden müssen.
Eine optimistische Sperre müssen Sie explizit mit einer LOCK-Anweisung anfordern. Wenn für ein Datenbankobjekt bereits eine Schreibsperre besteht, dann können Sie keine optimistische Sperre setzen (Sperrkollision). Bei einer bestehenden optimistischen Sperre für ein Datenbankobjekt können andere Benutzer weiterhin Schreib-, Lese- oder weitere optimistische Sperren setzen.
Bevor eine Transaktion eine von ihr optimistisch gesperrte Tabellenzeile ändern kann, prüft das Datenbanksystem, ob die Tabellenzeile seit dem Setzen der optimistischen Sperre von einem anderen Benutzer geändert wurde.
● Wenn die Tabellenzeile nicht geändert wurde, wandelt das Datenbanksystem zunächst die optimistische Sperre in eine Schreibsperre um und nimmt dann die Änderungen vor.
● Wenn eine andere Transaktion die Tabellenzeile inzwischen geändert hat, weist das Datenbanksystem die Änderungsoperation zurück und gibt die optimistische Sperre frei.
Eine optimistische Sperre ist nur dann sinnvoll, wenn Sie einen der folgenden Isolation-Level konfiguriert haben: 0, 1, 10 oder 15
Siehe auch: