Record-Lock mit SQL

[dschroeder]

Hallo,

ich habe da auch mal wieder eine Frage. Bisher sind viele Editierprogramme bei uns so gestaltet, dass der zu editierende Datensatz am Anfang des Programms gesperrt wird und zum Schluss ein Update (bzw. ein Unlock, falls nichts verändert wurde) durchgeführt wird. Durch die Sperre am Anfang wird verhindert, dass ein anderer User den Datensatz ebenfalls im Editiermodus aufrufen kann (Im Anzeigemodus kann er den Satz natürlich aufrufen). Wir möchten gerne noch viel mehr mit embedded SQL machen und fragen uns, wie wir so ein Record-Locking mit SQL machen können. (Ich meine damit nicht, dass wir den Sperrmechanismus selber bauen wollen). Gibt es im SQL etwas, das eine Satzsperre durchführt, so wie es im satzweisen Lesen bei RPG geht?

Zur Klarstellung: Das Verhalten des Programms ist so gewünscht. Wir möchten nicht, dass 2 User gleichzeitig den Datensatz editieren und zum Schluss einer der User die Meldung bekommt "Pech gehabt. Der Satz wurde inzwischen geändert".

Vielen Dank im Voraus,

Dieter

[BenderD]

... im richtigen Leben macht man das mit Commitment controll, da kann man die Sperrmechanismen feinkörnig steuern, wie man es braucht.

D*B

[B.Hauser]

Ich vermute in den bisherigen RPG-Programmen waren/sind die Dateien in den F-Bestimmungen als Update-Files definiert. Beim Chain wird der Datensatz gesperrt bis entweder ein Update (oder Delete) erfolgt oder der nächste Datensatz eingelesen wird.

Ich nehme weiterhin an, dass nicht mit Commitment Control gearbeitet wird.

Eine vergleichbare Situation kann man mit (embedded) SQL dadurch erreichen, dass ein updatefähiger Cursor (d.h. z.B. Joins sind nicht zulässig) definiert wird. Weiterhin muss ein Update auf den Cursor mit der Angabe WHERE CURRENT OF CURSOR erfolgen. Beim Fetch wird dann der Datensatz gesperrt (analog CHAIN, READ oder READE einer Update File) und beim Update (über WHERE CURRENT OF) oder beim Lesen des nächsten Satzes wieder freigegeben.

Wenn es allerdings lediglich darum geht simple Chains und anschließende Updates zu ersetzen, würde ich empfehlen auch weiterhin native I/O verwenden. Stattdessen sollten die Zugriffe lieber gekapselt in eigene Prozeduren ausgelagert werden.

Birgitta

[BenderD]

... von solchen Würgdrumherums würde ich dringlich abraten, das widerspricht der SQL denke, dem SQL Standard und verzichte´t auf die volle Mächtigkeit von SQL.

D*B

Ich vermute in den bisherigen RPG-Programmen waren/sind die Dateien in den F-Bestimmungen als Update-Files definiert. Beim Chain wird der Datensatz gesperrt bis entweder ein Update (oder Delete) erfolgt oder der nächste Datensatz eingelesen wird.

Ich nehme weiterhin an, dass nicht mit Commitment Control gearbeitet wird.

Eine vergleichbare Situation kann man mit (embedded) SQL dadurch erreichen, dass ein updatefähiger Cursor (d.h. z.B. Joins sind nicht zulässig) definiert wird. Weiterhin muss ein Update auf den Cursor mit der Angabe WHERE CURRENT OF CURSOR erfolgen. Beim Fetch wird dann der Datensatz gesperrt (analog CHAIN, READ oder READE einer Update File) und beim Update (über WHERE CURRENT OF) oder beim Lesen des nächsten Satzes wieder freigegeben.

Wenn es allerdings lediglich darum geht simple Chains und anschließende Updates zu ersetzen, würde ich empfehlen auch weiterhin native I/O verwenden. Stattdessen sollten die Zugriffe lieber gekapselt in eigene Prozeduren ausgelagert werden.

Birgitta

[andreaspr@aon.at]

Beim Fetch wird dann der Datensatz gesperrt (analog CHAIN, READ oder READE einer Update File) und beim Update (über WHERE CURRENT OF) oder beim Lesen des nächsten Satzes wieder freigegeben.

Nach einem UPDATE selbst wird der Satz nicht freigegeben.
Du kannst auch mehrere UPDATEs hintereinander durchführen. Erst nach dem CLOSE oder FETCH wird der gesperrte Satz wieder freigegeben.
Habe damit nämlich auch letztens wieder zu tun gehabt.

lg Andreas

[dschroeder]

Tja, erstmal vielen Dank für die zahlreichen Antworten. Ich muss zugeben, dass ich immer noch nicht so genau weiß, was der beste Weg ist. Ist es nicht so, dass man für Commitment Control Journaling braucht? Das hatten wir bisher nicht auf allen Tabellen. Aber jetzt wird bei uns gerade ein iCluster aufgesetzt und damit bekommen wir das flächendeckend. Birgitta hat genau erkannt, was wir wollen: Ein simpler chain mit dem Primärschlüssel und einige Zeit später (nachdem der User etwas editiert hat) ein Update (oder Unlock auf dem Datensatz). Die meisten anderen Zugriffe machen wir bei uns bereits per SQL. Bei dem oben beschriebenen Problem würden wir am liebsten gar keinen Cursor definieren und den Satz mit fetch einlesen. Stattdessen würden wir gern mit "Select * into " arbeiten. Wir wissen ja, dass wir nur genau einen Datensatz lesen werden (Primärschlüssel im where).

Wenn noch jemand einen guten Gedanken hat, immer her damit. Ansonsten werde versuchen, nochmal ein wenig in der Literatur zu stöbern.

Vielen Dank soweit.

Dieter

[camouflage]

Der Lock mit SQL geht nur mit einem Pointer. Die sauberste Lösung ist die, die D.B. beschrieben hat: Commitment Control und Journaling.

[S.Neinawaie]

Der Lock mit SQL geht nur mit einem Pointer. Die sauberste Lösung ist die, die D.B. beschrieben hat: Commitment Control und Journaling.

Hallo!

Könntest du bitte etwas genauer erklären was du damit meinst? (bezüglich Lock und Pointer höre ich zum ersten Mal)

Danke,
Saman

[camouflage]

Hier ein kleines Beispiel

C/EXEC SQL 
C+ Declare Cursor .... 
C+ For Update Of Field1, Field2, .... FieldN 
C/END-EXEC
 
C/EXEC SQL Open Cursor 
C/END-EXEC
 
C* The record gets locked with the FETCH statement 
C/EXEC SQL Fetch next From Cursor 
C/END-EXEC
 
C* Do some processing 
C* .....
 
C/EXEC SQL Update .... 
C+ Set Field1 = :X, Field2 = :Y, .... FieldN = :N 
C+ Where Current of Cursor 
C/END-EXEC
 
C/EXEC SQL Close Cursor 
C/END-EXEC 

Chain/Update ist halt schon ein bisschen einfacher, wer's mag.

[andreaspr@aon.at]

Dann meinst du wohl mit Pointer eigentlich einen SQL Cursor!?!

Ich würde das Beispiel so schreiben:

D tab1ds    E DS          extname(Tab1)
/Free
 EXEC SQL Declare c1 Cursor For Select * From Tab1
   For Update;
 
 EXEC SQL Open Cursor;
 
 // The record gets locked with the FETCH statement 
 EXEC SQL Fetch Cursor Into :tab1ds;
  
 // Do some processing 
 
 EXEC SQL Update Tab1 set Row = (:tab1ds) Where Current of c1;

 EXEC SQL Close Cursor;
/End-Free

Dadurch braucht man bei Tabellenänderungen das Programm einfach nur neu erstellen lassen, wenn nötig. Und man ersparrt sich die angabe jeder Spalte.
Und Free ersparrt auch ein paar Zeilen

lg Andreas

[B.Hauser]

Hier ein kleines Beispiel

C/EXEC SQL 
C+ Declare Cursor .... 
C+ For Update Of Field1, Field2, .... FieldN 
C/END-EXEC
 
C/EXEC SQL Open Cursor 
C/END-EXEC
 
C* The record gets locked with the FETCH statement 
C/EXEC SQL Fetch next From Cursor 
C/END-EXEC
 
C* Do some processing 
C* .....
 
C/EXEC SQL Update .... 
C+ Set Field1 = :X, Field2 = :Y, .... FieldN = :N 
C+ Where Current of Cursor 
C/END-EXEC
 
C/EXEC SQL Close Cursor 
C/END-EXEC 

Chain/Update ist halt schon ein bisschen einfacher, wer's mag.

Das ist doch genau das, was ich zuvor vorgeschlagen habe?!

Birgitta

[B.Hauser]

[QUOTE=dschroeder;81818]Ist es nicht so, dass man für Commitment Control Journaling braucht?
[QUOTE]

Journaling bzw. die Aufzeichnung der physischen Dateien bzw. SQL Tabellen im Journal ist die Voraussetzung für die Verwendung von Commitment Control.

Bei dem oben beschriebenen Problem würden wir am liebsten gar keinen Cursor definieren und den Satz mit fetch einlesen. Stattdessen würden wir gern mit "Select * into " arbeiten. Wir wissen ja, dass wir nur genau einen Datensatz lesen werden (Primärschlüssel im where)

... nur beim SELECT ... INTO kann kein Satz gesperrt werden, da "under the cover" immer ein OPEN, FETCH, CLOSE erfolgt.

@Andreas
Der Datensatz wird beim Update zwar freigegeben, da der Cursor (beim Update) nicht weiterbewegt wird und auf dem Satz bleibt, kann erst nach dem nächsten Fetch bzw. Close wieder auf den Satz im Update-Modus zugegriffen werden.

Birgitta