JDBC Zugriffsprobleme mit "concurrent access resolution"=last commited

[Noob]

Hallo zusammen,

ich schreibe aktuell ein Java Programm und greife konkurrierend mit RPG Programmen auf dieselben Daten zu. Im Java Programm verwende ich Transaktionen, die RPG Programme tun dies nicht (und können aktuell auch nicht auf Transaktionssteuerung umgestellt werden).

Der lesende Zugriff aus Java ist folgenden Treibereinstellungen spezifiziert:

readOnly = true
isolation level=*CS
concurrent access resolution=last commited


Es passiert nun immer wieder, dass ich beim lesenden Zugriff über Java einen Fehler bekomme, dass das Objekt gesperrt ist und nicht gelesen werden kann ("SQL-Fehler: -819").
Nach meinem Verständnis sollte eigentlich in diesem Fall bei meinen Treibereinstellungen der letzte committete Stand aus dem Journal gelesen werden.
Wenn ich aus einem Java-Programm innerhalb einer Transaktion ein Schreib-Lock erzeuge und das Programm anhalte (d.h. den Satz gesperrt halte), dann funktioniert auch alles wie erwartet.
Ich konnte es zwischenzeitlich darauf einschränken, dass im Fehler-Fall der zu lesende Record nicht im Journal enthalten ist (wenn ich vor dem Nachstellen der Situation per SQL ein Update auf den betroffenen Satz mache, dann ist das Verhalten wieder wie erwartet).


Meine Vermutung ist nun, dass hier bei Schreibenden Zugriffen ohne Transaktionssteuerung (also z.B. aus den RPG Programmen), das Vorhalten des letzten committeten Standes im Journal nicht passiert.


Gibt es hier eine Einstellung, die das benötigte Verhalten erzwingen würde (also quasi eine Pseudo-Transaktion erzeugt, falls ohne Transaktionssteuerung geschrieben werden soll)?

Oder bin ich hier völlig auf dem Holzweg?

Liebe Grüße

Noob

[Fuerchau]

Ja du bleibst auf dem Holzweg, da du hier die Frage bereits gestellt hast:
http://newsolutions.de/forum-systemi...-last-commited

Daher nochmal:
"das Vorhalten des letzten committeten Standes im Journal nicht passiert" => das gibt es nicht in der DB2 for i
"Satzversionen" werden nicht unterstützt, so wie es der SQL-Server nur u.U. macht.
Beim SQL-Server ist es sogar noch schlimmer, da fast jeder SQL-Befehl die gesamte Tabelle gegen Änderungen schützt, selbst beim einfachen Select.

https://www.ibm.com/support/knowledg...bafydicomm.htm