Record-Lock mit SQL

[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

[BenderD]

Unter dem passenden Commit Level wird der Satz auch beim select into gesperrt. Schau Dir mal die Commit Level Einstellungen an.
BTW: Einsatz von SQL ohne Commit Steuerung ist ein ernsthafter Designfehler, das machen nur Wahnsinnige und/oder Ahnungslose!!! Und der Einsatz von Journaling ist auch ohne Einsatz von Commit von großem Nutzen!!!

D*B

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]

@Birgitta
Bin ganz bei dir, dachte nur ich stell das Ganze ein bisschen strukturierter dar.

Und bzgl. des Pointers war ich wohl etwas abwesend, meinte natürlich schon den Cursor.

[Fuerchau]

@Andreas
Mehrere Updates bleiben nur gesperrt, wenn man unter CommitControl arbeitet.
Satzsperren aller Aktionen bleiben dann bis zum Commit/Rollback erhalten.
Dies geht auch über einen Close hinaus.

[andreaspr@aon.at]

@Andreas
Mehrere Updates bleiben nur gesperrt, wenn man unter CommitControl arbeitet.
Satzsperren aller Aktionen bleiben dann bis zum Commit/Rollback erhalten.
Dies geht auch über einen Close hinaus.

Das stimmt wenn du ein einfaches UPDATE durchführst.
Jedoch im angegebenen Beispiel sperrt der Cursor den Satz.
(siehe auch Kommentar von Birgitta)

[Fuerchau]

Du meintest also mehrere Updates auf dem selben Satz.
Aber auch SQL verlangt nach einem Update einen neuen Read / Fetch, da ein Update die Sperre (ohne CommitControl) wieder aufhebt, da ein "Update current" ohne Read nicht geht.