JDBC Zugriffsprobleme mit "concurrent access resolution"=last commited

[Noob]

Hallo zusammen,

ich versuche aus einem Java Programm mit den folgenden Einstellungen im Treiber einen Datensatz zu lesen (Über die "SQL Scripts ausführen" Oberfläche der "IBM i Access Client Solutions" lässt sich das Problem identisch reproduzieren, deshalb der Screenshot)


Der Datensatz ist durch ein RPG Programm das ohne Commitsteuerung arbeitet zum Schreiben gesperrt.

Leider bekomme ich immer wieder den Fehler [SQL0913] "Zeile oder Objekt wird ... verwendet".

Ich konnte das Problem so weit eingrenzen, dass der Fehler immer dann auftritt wenn der Datensatz nicht im Journal vorgehalten wird (was dann ja auch logisch ist, es gibt dann ja nichts was geliefert werden könnte).

Meine Vermutung ist nun, dass die Schreibsperre aus dem RPG Programm nicht dafür sorgt, dass der letzte Commit-Stand im Journal vorgehalten wird.

Sollte die Vermutung korrekt sein die vorsichtige Frage, ob es eine Möglichkeit gibt dafür zu sorgen, dass für Datensätze auf die ohne Commitsteuerung eine Schreibsperre angefordert wird der letzte Commit-Stand im Journal vorgehalten wird (so 'ne Art Pseudo-Transaktion).

Commit-Steuerung in das RPG-Programm einzubauen ist aktuell keine Option.

Einzige Alternative die ich sehe, wäre auf READ_UNCOMMITED zurück zu gehen (was ich ungern tun würde...)

Danke schon mal für das Feedback.


Liebe Grüße

René

[Fuerchau]

Ohne Journalisierung geht bzgl. der Commit-Steuerung sowieso nichts.
Somit ist eine Commit(*CS) wenig sinnvoll.
Der Standard ist eigentlich auch eher Commit(*CHG), so dass beim Lesen auch keine Sperre geprüft wird.

Und das Journal ist nur ein Protokoll, dass u.U. für einen Rollback benötigt wird.
Ein Select geht somit immer auf die aktuelle Information der Tabelle und somit auch auf nicht bestätigte Informationen (Problem "Schmutzdaten").

Durch Commit(*CS) erzwingst du das Warten auf die Satzfreigabe, die ohne Journal nur durch Unlock (Close, Lesen andere Zeile) und mit Journal nur per Commit/Rollback aufgehoben wird.

Da die zu verarbeitende Tabelle nicht journalisiert ist, hast du eher 2 Varianten:
Commit(*NONE), Commit(*CHG) oder "select .... with nc".
"with nc" = "No Commit" => Die Daten werden trotzdem gelesen.

[Fuerchau]

Nachtrag:
"Satzversionen" wie sie u.U. beim SQL-Server auftreten oder bei Firebird standard sind, gibt es bei der IBM i nicht, man kann also nicht auf ältere Transaktionsdaten zurückgreifen.
M.a.W: "last committed" wird nicht unterstützt.

[Fuerchau]

Nachtrag 2:
Commit(*CS) hat den weiteren Nachteil, dass alle deine Selects bereits die Daten auch für andere sperren.
Somit bekommen alle anderen bei längeren Transaktionen deinerseits dieselben Probleme wie du.
Des weiteren können durchaus sehr viele Ressourcen im System benötigt werden, die die Transaktionszeiten auch noch verlängern.