[NEWSboard IBMi Forum]
Seite 1 von 2 1 2 Letzte

Thema: WRKOBJLCK

  1. #1
    Registriert seit
    Aug 2011
    Beiträge
    93

    WRKOBJLCK

    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. :-)
    Oder kann ich das auch per SQL rausfinden? und wenn ja wie? :-D

    Vielen Dank
    Gruss
    Manfred

  2. #2
    Registriert seit
    Dec 2004
    Beiträge
    203
    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

  3. #3
    Registriert seit
    Aug 2011
    Beiträge
    93
    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.

  4. #4
    Registriert seit
    May 2002
    Beiträge
    1.121
    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

  5. #5
    Registriert seit
    Mar 2002
    Beiträge
    5.286
    ... 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
    AS400 Freeware
    http://www.bender-dv.de
    Mit embedded SQL in RPG auf Datenbanken von ADABAS bis XBASE zugreifen
    http://sourceforge.net/projects/appserver4rpg/

  6. #6
    Registriert seit
    Aug 2011
    Beiträge
    93
    @ 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 :-)

  7. #7
    Registriert seit
    Mar 2002
    Beiträge
    5.286
    Zitat Zitat von malzusrex Beitrag anzeigen
    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.
    AS400 Freeware
    http://www.bender-dv.de
    Mit embedded SQL in RPG auf Datenbanken von ADABAS bis XBASE zugreifen
    http://sourceforge.net/projects/appserver4rpg/

  8. #8
    Registriert seit
    Feb 2001
    Beiträge
    20.206
    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.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

  9. #9
    Registriert seit
    Aug 2011
    Beiträge
    93
    Zitat Zitat von Fuerchau Beitrag anzeigen
    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. :-)

  10. #10
    Registriert seit
    Mar 2002
    Beiträge
    5.286
    Zitat Zitat von Fuerchau Beitrag anzeigen
    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
    AS400 Freeware
    http://www.bender-dv.de
    Mit embedded SQL in RPG auf Datenbanken von ADABAS bis XBASE zugreifen
    http://sourceforge.net/projects/appserver4rpg/

  11. #11
    Registriert seit
    Mar 2002
    Beiträge
    5.286
    Zitat Zitat von Mr-Ferret Beitrag anzeigen
    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.
    AS400 Freeware
    http://www.bender-dv.de
    Mit embedded SQL in RPG auf Datenbanken von ADABAS bis XBASE zugreifen
    http://sourceforge.net/projects/appserver4rpg/

  12. #12
    Registriert seit
    Jan 2001
    Beiträge
    832
    Hallo Manfred,

    zuerst sollte man herausfinden welchen commit status die Javajobs benutzen
    Werden Tabellen gesperrt ? oder nur Sätze in den Tabellen ?

    Nachzulesen ist das sehr schön im STRSQL und F13 Commit Steuerung
    PHP-Code:
                    COMMIT-Steuerung Hilfetext           
                                                           
     
    Die Art der COMMIT-Steuerung auswählenGültige Werte 
     sind
    :  
    .............................. 
    Gruß
    Michael

Tags for this Thread

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • You may not post attachments
  • You may not edit your posts
  •