Locking ohne Transaktion

Hi,

in manchen Datenbanken ist es möglich, mit Select … For Update einen Datensatz (für andere Benutzer) zu sperren, auch ohne vorher eine Transaktion gestartet zu haben. Postgres scheint das aber völlig schnuppe zu sein, ich kann in der Anwendung problemlos in zwei separaten Connections denselben Datensatz mit Select For Update lesen. Starte ich zuvor eine Transaktion, bekomme ich in der zweiten Sitzung die erwartete Meldung bzgl. der Satzsperre.

Geht das in PG tatsächlich nur mit einer explizit gestarteten Transaktion [in JDBC setAutoCommit(false)]? Das würde für meine Migration zu PG bedeuten, nicht nur zig SQL-Anweisungen auf Kompatiblität zu prüfen sondern auch noch an Hunderten Stellen Transaktionen einzubauen :frowning: Bisher setze ich Transaktionen eigentlich nur ein, wenn Daten in mehreren Tabellen synchron gehalten werden müssen. Bei der simplen interaktiven Bearbeitung eines einzelnen Datensatzes hatte ich diese Anforderung bisher nicht :slight_smile:

BTW: Mit Transaktion greift scheinbar das Setting deadlock_timeout hierbei nicht, erst wenn ich lock_timeout setze, erhalte ich die Satzsperre-Meldung. Ist das “works as designed”?

Wenn Du mit setAutocommit(true) arbeitest, dann kann das gar nicht funktionieren - auch nicht “mit anderen Datenbanken” (egal welche Du da genau meinst).

Wenn auto commit ausgeschaltet ist, dann musst Du nicht explizit eine Transaktion starten - genau wie in “anderen Datenbanken”. Dann wird implizit eine gestartet sobald Du ein SQL statement ausführst. Du musst dann allerdings dafür sorgen, dass diese auch mit commit (oder rollback) beendet wird - genauso wie in “anderen Datenbanken”.

Zumindest bei der DB2 für IBM System i (früher AS/400) geht das ohne Probleme. AutoCommit true und Select For Update sperrt den Datensatz definitiv für andere User.