View Full Version : Sichtbarkeit von 'uncommited data' durch andere Sessions
Hallo Zusammen,
ich habe eine Frage zur Verarbeitung mit Commit Steuerung.
Folgendes möchte ich erreichen:
Session A schreibt Satz in Datei als 'uncommited data'.
Session B soll diesen Satz zu keiner Zeit sehen dürfen, d.h. Session B soll nur 'commited data' sehen dürfen.
Session A schreibt den Datensatz wie folgt:
exec sql set option commit *cs;
insert into ....;
Session B führt nun folgenden 'select' aus:
select * from ... with cs
Leider kann der 'select' in Session B nicht ausgeführt werden, weil der eine Satz gesperrt ist. Ich hätte gedacht er würde wenigstens die anderen Datensätze anzeigen.
Ist das generell möglich bzw. was mache ich falsch?
Gruß
derMuller
Das ist bei der AS/400 "state of the art".
D.h., es werden keine Satzversionen für alte Transaktionen vorgehalten (SQL-Server Snapshot, Firebird, o.ä.).
Deshalb sind veränderte und neue Datensätze in einer offenen Transaktion gesperrt, bis der Commit/Rollback erfolgt.
Eine andere Transaktion wartet mit "Read commited" also auf die Freigabe der Sperre.
Bei "Read uncommited" wird nicht gewartet sondern der geänderte/neue Satz tatsächlich gelesen.
Da nicht feststellbar ist, ob der Satz auch tatsächlich gültig ist, kann man sich u.U. nicht auf die Information verlassen.
Da beim Lesen ja über die Satzwartezeit der Datei (default 1 Minute) gewartet wird, sollte also eine Transaktion, die Sperren hält, nie länger als die Satzwartezeit andauern.
Anwendungsentwicklung => Transaktionskonzept!
Der lesende SQL erfährt über SQLCODE/SQLSTATE warum das Lesen nicht erfolgreich war.
Ggf. musst du für deinen Select die Anzahl gelesener Sätze zählen und per "select ... offset n rows" den gesperrten Satzt überspringen.
Ob dabei allerdings Sperren ignoriert werden kann ich nicht sagen.
... der Satz wird schon überlesen, allerdings zieht der record wait der Datei (der den idiotischen Default 60 sec. hat - bei waitfile *immed) und es wird ein negativer SQLCODE, bzw. eine CPF zurück gemeldet. Lösung ist also:
1.) OVRDBF FILE(xxx) WAITRCD(*IMMED) für den lesenden Job
2.) Monitor Gruppe um den fetch und Fehler ignorieren
D*B
PS: set option zieht nur zur compile time. set transaction kann zur Laufzeit verwendet werden.
Den OVRDBF müsste ich ja für alles verwenden.
Damit hätte ich bei SQL aber tatsächlich das Problem, dass jede Transaktion (schließlich lese ich ja nicht nur) durch die nicht vorhandenen Wartezeit scheitert, sobald irgend wo ein Lock vorliegt.
Und beim sequentiellen lesen konnte ich im Updatemodus noch nie über Satzsperren wegkommen und im Input-Modus lese ich auch uncommited Daten.
Den OVRDBF müsste ich ja für alles verwenden.
Damit hätte ich bei SQL aber tatsächlich das Problem, dass jede Transaktion (schließlich lese ich ja nicht nur) durch die nicht vorhandenen Wartezeit scheitert, sobald irgend wo ein Lock vorliegt.
Und beim sequentiellen lesen konnte ich im Updatemodus noch nie über Satzsperren wegkommen und im Input-Modus lese ich auch uncommited Daten.
... der OVRDBF wird nur in dem Job abgesetzt, der die Sätze überlesen soll. Sinn und Zweck der Angelegenheit sind transaktions sichere Auswertungen während des laufenden Betriebs (wobei das durchaus komplex werden kann). Unbeschadet dessen ist der Record Wait mit 60 sec. absolut schwachsinnig, was nach 2 Sekunden nicht frei ist, das kann die ganze Mittagspause dauern (wenn man das falsch macht, was manche für richtig halten).
Ich hab's nicht ausprobiert, aber was passiert, wenn Du ans Ende des SELECT-Statements
SKIP LOCKED DATA hinzufügst?
Birgitta
... die concurrent-access-resolution-clause sollte auch gehen, ich weiß allerdings nicht wann das kam.
Danke für die zahlreichten Lösungsvorschläge.
Leider war keiner davon für mein Vorhaben 100% nutzbar.
Habe es nun aners gelöst, aber schön zu sehen dass wieder viele Wege nach Rom führen! ;)
Hi,
interessanter Post.
Für die Mitlesenden wäre aber die Lösung auch schön.