WRKOBJLCK

[Mr-Ferret]

Hallo Gemeinde,

jetzt werden evtl. 95% der Leser lachen, aber ich kapier's nicht!

Von unserem ERP-System werden immer mehr Daten von anderen Anwendungen / Usern ueber SQL geladen. Bisher war das auch kein Problem, nun passiert es aber immer oefter, das manche Tabellen fuer andere Anwendungen (auch fuer das ERP System) geblockt sind. Das hatte gestern z.B. zur Folge das keine Ausdrucke mehr moeglich waren. Ich kann zwar feststellen, welche Tabelle betroffen ist, aber ich kann nicht mit Sicherheit sagen wer die Tabelle blockiert.
Wenn ich da mit WRKOBJLCK rangehe, dann sehe ich einen ganzen A.... von Anwendungen / Usern die auf die Tabelle zugreifen, aber wer ist fuer den Lock verantwortlich?
Daher dieser Beitrag mit der eigentlichen Frage:

Wie bzw. Wo erkennt man / ich, welcher User die Tabelle sperrt?
Zumal ich eigentlich dachte (falsch gedacht) das die Tabellen alle den Modus *SHRRD haben, diese gar nicht gelockt werden koennten.

Vielleicht ist ja jemand von euch so freundlich und erklaert mir das nach dem Motto WRKOBJLCK fuer Dummies! Dann versteh ich das evtl. :D:-)
Oder kann ich das auch per SQL rausfinden? und wenn ja wie? :-D

Vielen Dank
Gruss
Manfred

[TheDevil]

Guten Morgen.
Der Job der z. B. die Ausdrucke erstellt geht dann nicht in ein MSGW Status ?
Wenn doch dann sollte im Jobprotokoll des aktiven "Ausdruck" Jobs stehen welcher
Job hier das Problem verursacht.
Gruß,
Ralf

[Mr-Ferret]

Hallo Ralf,
nein, der Job welcher die Ausdrucke bearbeitet, ist ein Java Job des ERP Systems, diesen sieht man in der TN5250 gar nicht. Wir haben ein Webinterface, dort sieht man den Job mit der Meldung das Tabelle xxxx einen READLOCK hat. Unser ganzes ERP-System läuft in Java :-(
Ich kann natürlich auch die Jobs killen, welche im ERP-System betroffen sind, aber damit bekomme ich die Ursache nicht raus. Ich möchte den User erwischen der für das / die Problem verantwortlich ist. Das sind eben die SQL Jobs.

[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]

... da ist kein User für verantwortlich, sondern ein Programmierer, der sein Handwerk nicht versteht! Hat denn die Java Anwendung wenigstens einen Logging Mechanismus? Üblicherweise ist das dann konfigurierbar.

D*B

[Mr-Ferret]

@ Ronald, danke werde ich versuchen sobald das Prob. wieder auftaucht, wird wohl nicht lange dauern :-(

@ BenderD, Solange niemand von aussen auf das ERP-System zugreift (SQL) hatte ich das Problem nicht, aber mit dem Programmierer gebe ich dir recht. Getreu nach dem Motto: Das Problem sitzt eine halben Meter vor dem Bildschirm :-)

[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]

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