-
JDBC Zugriffsprobleme mit "concurrent access resolution"=last commited
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é
-
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.
-
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.
-
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.
Similar Threads
-
By Starocotes in forum IBM i Hauptforum
Antworten: 15
Letzter Beitrag: 25-10-19, 12:35
-
By bie-dro in forum IBM i Hauptforum
Antworten: 12
Letzter Beitrag: 15-04-16, 20:06
-
By Edi in forum IBM i Hauptforum
Antworten: 8
Letzter Beitrag: 07-11-14, 07:52
-
By RLurati in forum NEWSboard Programmierung
Antworten: 1
Letzter Beitrag: 05-08-14, 09:10
-
By iseries_user in forum IBM i Hauptforum
Antworten: 7
Letzter Beitrag: 11-04-13, 07:59
Tags for this Thread
Berechtigungen
- Neue Themen erstellen: Nein
- Themen beantworten: Nein
- You may not post attachments
- You may not edit your posts
-
Foren-Regeln
|
Erweiterte Foren Suche
Google Foren Suche
Forum & Artikel Update eMail
AS/400 / IBM i
Server Expert Gruppen
Unternehmens IT
|
Kategorien online Artikel
- Big Data, Analytics, BI, MIS
- Cloud, Social Media, Devices
- DMS, Archivierung, Druck
- ERP + Add-ons, Business Software
- Hochverfügbarkeit
- Human Resources, Personal
- IBM Announcements
- IT-Karikaturen
- Leitartikel
- Load`n`go
- Messen, Veranstaltungen
- NEWSolutions Dossiers
- Programmierung
- Security
- Software Development + Change Mgmt.
- Solutions & Provider
- Speicher – Storage
- Strategische Berichte
- Systemmanagement
- Tools, Hot-Tips
Auf dem Laufenden bleiben
|
Bookmarks