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

Thema: WRKOBJLCK

  1. #13
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    Das Standardverhalten ist "Beim Lesen werden (im Modus *CHG bzw. Read Committed)..."
    Wer Serializable verwendet, merkt sowas i.d.R. schon bei der Entwicklung, da fast grundsätzlich keine parallelen Transaktionen mehr möglich wären.

    Was das Feststellen des Users angeht, so ist das tatsächlich ein Problem, da alle ODBC-Jobs (QZDASOINIT) mit dem Namen QUSER verheiratet sind.
    Erst SQL setzt den tatsächlichen User per API (QSYSETPH), was über einen Joblog-Eintrag festgehalten wird.
    Nun müsste man also nach dem Laden der Sperrinformationen (anderer Thread) per SQL, aus jedem Sperrjob das Joblog auslesen und nach dieser Nachricht (die ich im Moment jetzt nicht parat habe) scannen, die den User benennt.
    Aber Achtung: Da QZDA-Jobs von anderen Verbindungen wiederverwendet werden, muss man diesbezüglich den letzten Eintrag im Joblog suchen.
    Wenn man aber von der Anwendung sich mit einem sog. "App-User" anmeldet, hat man diesbezüglich leider verloren.

    @Dieter
    Seit wann werden Locks im Journal aufgezeichnet?
    Na gut, bei offenen Transaktionen fehlt noch der Commit-Eintrag, also ist von einer Sperre auszugehen.
    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

  2. #14
    Registriert seit
    Mar 2002
    Beiträge
    5.286
    Zitat Zitat von Fuerchau Beitrag anzeigen
    Wenn man aber von der Anwendung sich mit einem sog. "App-User" anmeldet, hat man diesbezüglich leider verloren.

    @Dieter
    Seit wann werden Locks im Journal aufgezeichnet?
    Na gut, bei offenen Transaktionen fehlt noch der Commit-Eintrag, also ist von einer Sperre auszugehen.
    ... AppUser und Connection Pool wäre eigentlich Standard, das Problem sieht für mich aber eher nach Java Anwendung in RPG Denke aus...

    Wenn man den Zeitpunkt kennt, sieht man im Journal sehr schön, welche Transaktionen offen waren. Ein anderer Einstieg wäre, die Journaleinträge nach CommitCycle ID, begin und end Einträgen auszuwerten (Ausgabe in outfile und SQL) und die lang andauernden Transaktionen zu suchen.

    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/

  3. #15
    Registriert seit
    Aug 2011
    Beiträge
    93
    Ich möchte mich erst mal bei allen für die Antworten bedanken!

    Soweit ich das jetzt beurteilen kann, liegt es nicht an unserer ERP Anwendung, sondern an den vielen Schnittstellen. Es ist leider so, das es eine Menge an anderen Produkten bei uns gibt, ich sag nur BI, DWH, SER, ...., die alle Daten aus der ERP Anwendung bzw. von den Platten saugen. Dann gibt es noch User die mit SQL drauf zugreifen. Ich möchte jetzt nicht behaupten das die Leute immer wissen was sie tun, im Gegenteil. Wir werden wohl in den nächsten Tagen Schritte einleiten damit diese Fälle weniger werden. In manchen Fällen konnte ich auch schon im Log sehen wer eine Tabelle gesperrt hat.

    Von daher noch mal vielen Dank an alle.
    Gruß
    Manfred

  4. #16
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    Also Tabellensperren bei reinen Lesevogängen (User-Abfragen, Query, BI, DWH) halte ich für ein Gerücht oder schwere konzeptionelle Fehler.
    Bei Schnittstellen mit Updatefunktion dürften i.d.R. auch keine Sperrfunktionen über die Standardwartezeit hinaus auftreten.
    Und normale User dürften gar keine Updates außerhalb der ERP-Anwendung durchführen.

    Ich habe bei einem Kunden bestimmt schon an die 100 Schnittstellen über die letzten 20 Jahre geschrieben, wovon der größte Teil auch noch aktiv ist. Hier gibt es in keinster Weise irgendein Problem mit Tabellensperren.

    Die auftretende Fälle, wie du sie nennst, würden mich da schon mal interessieren.
    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

Tags for this Thread

Berechtigungen

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