WRKOBJLCK

[malzusrex]

Der WRKOBJLCK zeigt dir die Jobs/User die gerade auf das File zugreifen.
Das muss aber nicht heisen, das die auch einen Satz sperren.
Versuche es mal mit DSPRCDLCK

Gruß
Ronald

[BenderD]

Der WRKOBJLCK zeigt dir die Jobs/User die gerade auf das File zugreifen.
Das muss aber nicht heisen, das die auch einen Satz sperren.
Versuche es mal mit DSPRCDLCK

Gruß
Ronald

... das liefert dann den Serverjob (QZDAxxx o.ä. je nach Treiber), der die Sperre hat, was meist nicht viel weiterhilft.

[Fuerchau]

Da mit Java wohl auf die Datenbank nur mit SQL zugegriffen wird (ich glaube nicht dass hier per API ein RLA-Zugriff erfolgt), sollte sich die Sperre von Datensätzen eher in Grenzen halten.
Beim Lesen werden (im Modus *CHG bzw. Read Committed) keine Sperren gesetzt und gesperrte Daten trotzdem gelesen.
Table-Locks kann ich mir da nun überhaupt nicht vorstellen.
Es kann also nur sein, dass Transaktionen nicht vernünftig committed werden, somit offen bleiben und weitere Updates verhindern.
Mit der Grundaussage "Keine offene Transaktion über eine Userinteraktion hinaus", die man beherzigen sollte, dürfte das Problem überhaupt nicht auftreten.
Mit der Defaultsatzwartezeit von 60 Sekunden (je Lock!) gibt es auch kein Problem, da vernünftigerweise Transaktionen so lange gar nicht dauern dürften.

[Mr-Ferret]

Es kann also nur sein, dass Transaktionen nicht vernünftig committed werden, somit offen bleiben und weitere Updates verhindern.

Und da komme ich wieder mit der Frage:
Wie kann ich herausfinden, Wer die Tabelle / Satz im Zugriff hält. :-)

[BenderD]

Und da komme ich wieder mit der Frage:
Wie kann ich herausfinden, Wer die Tabelle / Satz im Zugriff hält. :-)

... falls eine schreibende Transaktion die Sperre hält, über das Journal.

[BenderD]

Table-Locks kann ich mir da nun überhaupt nicht vorstellen.
...
Mit der Grundaussage "Keine offene Transaktion über eine Userinteraktion hinaus", die man beherzigen sollte, dürfte das Problem überhaupt nicht auftreten.
Mit der Defaultsatzwartezeit von 60 Sekunden (je Lock!) gibt es auch kein Problem, da vernünftigerweise Transaktionen so lange gar nicht dauern dürften.

... commit level serialized setzt table locks!

Fehler im Transaktionsverhalten (lang andauernde Sperren) sind geradezu ein Kennzeichen, an dem man erkennt, wenn sich RPG Programmierre an Java versuchen.

Mit dem Waitrecord lässt sich kaum was anfangen, da der falsch programmierte Zugriff nicht abgebrochen wird, sondern der, der es richtig macht!!!

D*B