View Full Version : Record-Lock mit SQL
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
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.
[QUOTE=dschroeder;81818]
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 <Datenstruktur>" 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
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 <Datenstruktur>" 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
02-10-12, 18:40
@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.
@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
03-10-12, 13:10
@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)
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.
andreaspr@aon.at
03-10-12, 13:33
Du kannst es mal ausprobieren.
Nach dem Update ... where current of ... ist der selbe Satz immer noch gesperrt.
Erst nach einem fetch oder close wird der Satz endgültig freigegeben.
(Alles ohne Commitment Control)