Exception Handling bei Satzsperre in SQLRPGLE

[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

[BenderD]

... das ist auch bei RLA unter Commit schon anders!
nach dem read (bei open for update) kann ein zweiter noch lesen, aber nicht mehr schreiben
- schreibt einer unter commit, hält er die Sperre bis zum Ende der Transaktion, jetzt kann ein zweiter schon nicht mehr lesen.
- unter Commit hängt das dann noch von der Commitstufe ab, da werden bei repeatable read bereits beim lesen schon Sperren gesetzt und gehalten, bei read committed werden gesperrte Sätze überlesen, bei read uncommited wird gewartet, bei serializable werden table locks gesetzt, die den open for update von rla schon wechselseitig ausschließen...

D*B

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