Exception Handling bei Satzsperre in SQLRPGLE

[B.Hauser]

... nur leider gibt Get Diagnostics auch nur die Fehlermeldung, dass in der Datei eine Satz-Sperre vorliegt, aber nicht welcher Job bzw. welcher User welchen Satz blockiert.

Hier sind übrigens die Links zu den Online-Books:
SQL Reference - Release 6.1
Embedded SQL Programming - Release 6.1

Birgitta

[dabeda]

Du kannst über die API QGYOLJBL das Joblog auslesen und dir die Meldung holen die du brauchst. Leider ist das dann einfach ein ganzer Textstring ohne Variablen.

Alternativ kannst du bei einem Lock die relative Satznummer auslesen (select rrn(datei) from datei where ) und dann mit der API QDBRRCDL den Benutzer usw. auslesen. Das Ganze dann noch schön in einem Serviceprogramm verpackt und man merkt gar nicht mehr, dass SQL das eigentlich gar nicht kann. ;-)

MfG

[Fuerchau]

Wobei der Select RRN ganz schön dauert, da hier grundsätzlich kein Index verwendet wird.
Eine schnelle und vor allem gute Lösung ist das nicht.

Was ich mich allerdings frage, wieso der SELECT gesperrte Sätze nicht liest ?
Einen Fehler gibts eigentlich erst beim UPDATE/DELETE oder der gesperrte Satz wird einfach überlesen.

[dabeda]

So schnell wie im RPG ist das natürlich nicht, man kann aber beim declare cursor gleich die relative Satznummer mit auslesen, dann erspart man sich das nachher. Obwohl ich eingentlich nicht so viele Locks erwarte dass es zeitlich ein Problem wird die relative Satznummer auszulesen.
Glaube das Überlesen von gelockten Sätzen funktioniert erst bei V6.1, kann mich aber täuschen.

[Fuerchau]

Das Überlesen ist ja nicht das Problem.
Ich kann durchaus gesperrte Sätze lesen!

Allerdings darf ich den Cursor nicht als "for update" deklarieren, da im Falle des Lesens genau dann ein Sperre gesetzt wird und es ggf. zum Fehler kommt.

SQL-Like ist das nicht.
MS-Access / ADO.NET geht den "normalen" Weg, dass vor dem Update / Delete die aktuelle Information erst noch mal gelesen und mit dem vorherigen Zustand verglichen wird. Ist der Inhalt noch unverändert, wird geändert an sonsten ein Fehler ausgelöst.

Dies wäre das korrekte Anwendungsverhalten, denn eine potentielle Satzsperre ohne den tatsächlichen Wunsch einer Veränderung sollte nicht erfolgen.

[mwithake]

Wobei der Select RRN ganz schön dauert, da hier grundsätzlich kein Index verwendet wird. Eine schnelle und vor allem gute Lösung ist das nicht.

Das Stimmt nicht, Indexe werden auch zur Ermittlung von RRN() verwendet.

[Fuerchau]

Wenn du einen
select ... where rrn() = 1234
verwendest, kann SQL keinen Index verwenden, da es keinen Index über RRN gibt.
Schränkst du natürlich auf weitere Schlüssel ein, werden für diese natürlich Indizees verwendet.

[mwithake]

Wenn du einen
select ... where rrn() = 1234
verwendest, kann SQL keinen Index verwenden, da es keinen Index über RRN gibt.
Schränkst du natürlich auf weitere Schlüssel ein, werden für diese natürlich Indizees verwendet.

Es ging ja in dem Beitrag davor darum, die relative Satznummer zu ermitteln und Du hattes geschrieben, es würde sehr lange dauern.
Die Ermittlung geht durch einen entsprechenden Index sehr schnell und ich denke, das der Zugriff bzw. die Auswahl über relative Satznummer auch sehr schnell geht.

Die von dabeda angegeben Methode mittels QDBRRCDL nutzt ich übrigens für Java, um auf der Java-Oberfläche den zu blockierenden Benutzer anzeigen zu können. Das geht sehr fix.

[Fuerchau]

Dazum muss ich aber grundsätzlich den Schlüssel mit abfragen um einen Index zu benutzen.

[B.Hauser]

@Baldur

Was ich mich allerdings frage, wieso der SELECT gesperrte Sätze nicht liest ?
Einen Fehler gibts eigentlich erst beim UPDATE/DELETE oder der gesperrte Satz wird einfach überlesen.

Wird ein Cursor definiert und ein Update oder Delete mit WHERE CURRENT OF, wird i.d.R. nur ein einziger ODP (open data path) verwendet. Damit muss die Sperre bereits beim Fetch und nicht erst beim Update erfolgen.

(... genau wie beim native I/O in Update Dateien)

Wird ein Cursor definiert und z.B. die relative Satz-Nr. oder der unique Key zurückgebracht und der anschließende Update entweder über die relative Satz-Nr. oder den unique Key gemacht, werden 2 ODPs generiert (und damit natürlich auch 2 FULL OPENS ausgeführt). In diesem Fall erfolgt die Satz-Sperre erst beim Update.

(... man liest mit native I/O die Input-Datei ein und macht den Update auf die (gleiche) Update-Datei)

Birgitta

[BenderD]

... das hat mit den ODPs allenfalls mittelbar zu tun, sondern hängt davon ab welche Art von Sperre angefordert wird und welche Art von Sperre der Satz gegenwärtig hat. Das kann unter commit alles ein wenig anders aussehen...


D*B

@Baldur


Wird ein Cursor definiert und ein Update oder Delete mit WHERE CURRENT OF, wird i.d.R. nur ein einziger ODP (open data path) verwendet. Damit muss die Sperre bereits beim Fetch und nicht erst beim Update erfolgen.

(... genau wie beim native I/O in Update Dateien)

Wird ein Cursor definiert und z.B. die relative Satz-Nr. oder der unique Key zurückgebracht und der anschließende Update entweder über die relative Satz-Nr. oder den unique Key gemacht, werden 2 ODPs generiert (und damit natürlich auch 2 FULL OPENS ausgeführt). In diesem Fall erfolgt die Satz-Sperre erst beim Update.

(... man liest mit native I/O die Input-Datei ein und macht den Update auf die (gleiche) Update-Datei)

Birgitta

[B.Hauser]

... das hat mit den ODPs allenfalls mittelbar zu tun, sondern hängt davon ab welche Art von Sperre angefordert wird und welche Art von Sperre der Satz gegenwärtig hat. Das kann unter commit alles ein wenig anders aussehen...

Kann ich mir eigentlich nicht vorstellen, vielleicht bei den hohen Commit Leveln, bei denen der READ/FETCH gelockt wird. Aber da stellt ich die Frage, ob der Satz beim Fetch überhaupt gelesen werden kann oder nicht. Bei den niederen Commit Leveln z.B. *UR (Uncommitted Read) oder *CS (Cursor Stability) funktioniert es genau so wie ich es beschrieben habe.

Es soll übrigens Leute geben, die grundsätzlich mit Journaling und Commitment Control arbeiten

Birgitta

Birgitta