[NEWSboard IBMi Forum]
Seite 1 von 2 1 2 Letzte
  1. #1
    Registriert seit
    Jun 2014
    Beiträge
    7

    Query-Timeouts per JDBC

    Hallo zusammen,

    es deutet für uns darauf hin, dass das Setzen von Query-Timeouts per JDBC in der DB2 nicht unterstützt wird. Wir machen im Code etwa folgendes:

    Statement stmt = connection.createStatement();
    stmt.setQueryTimeout( seconds);
    stmt.execute….

    In allen anderen von uns getesteten DBMS funktioniert es so. Muss man die DB2/400 übern den Connection-String oder ähnliches erst konfigurieren? Gibt es diese Funktionalität möglicherweise dort gar nicht?

    Gruß
    Wwilson

  2. #2
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    Laut Dokumentation sollte es funktionieren:
    http://www.ibm.com/support/knowledge...meout%28int%29
    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

  3. #3
    Registriert seit
    Mar 2002
    Beiträge
    5.286
    ... als erste müsste man wissen, welcher Treiber verwendet wird...

    falls jtopen: die ursprüngliche Implementierung verwendete den QRYTIMLMT Mechanismus des Servers, der nur für queries zieht und einen vorab estimate verwendet. Das ist später mal geändert worden, für die neue Funktionalität muss ein Treiber Property "query timeout mechanism" auf cancel gesetzt werden. Geht wohl nur für Treiber ab einem gewissen Release und Server eines gewissen Releases und PTF und ob das funzt...

    Falls native oder DB2 Treiber: den würde ich ohnehin nicht über den Weg trauen...

    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/

  4. #4
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    Bzgl. Java kann ich da nicht so viel sagen.
    Irgend wann wurde die QAQQINI eingeführt. Diese lässt sich in einer Verbindung explizit angeben (Lib-spezifisch). Hier kann man auch das Query-Timelimit überschreiben. Wobei das vom Treiber unterstützt werden sollte.
    Bei CA-OLEDB/ODBC funktioniert dies jedenfalls, warum sollte es nicht auch bei JDBC funktionieren.
    Häufig muss ich das Limit auf weit über 3600 setzen da sich der Optimizer einfach zu sehr verschätzt und Abfragen z.T. gar nicht möglich wären.
    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

  5. #5
    Registriert seit
    Mar 2002
    Beiträge
    5.286
    ... die JDBC Spezifikation sagt, dass die Operation (select, update, delete, ...) nach dem gesetzten Timeout abgebrochen wird, die Angaben in der QAQQINI (und CHGQRYA QRYTIMLMT(xxx)) steuern nur, ob ein select statement überhaupt anläuft, falls irgend so ein Würfel Algorithmus meint, das könnte länger dauern...

    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
    Feb 2001
    Beiträge
    20.207
    Was da nun besser ist, da scheiden sich die Geister.
    Die AS/400 meint eben, ein längerer Query sollte erst gar nicht starten bevor er auf Grund Timeout dann abgebrochen wird.
    Beim Select ist das ja noch unkritisch.
    Problematisch wird es da eher beim Update/Delete wenn wie meistens ohne Journal gearbeitet wird.
    Beim Eintreten des Timeout müsste ja ein Rollback ausgeführt werden, wenn kein Journal aktiv ist.
    Habe ich ein Journal kann ich ja einen Rollback durchführen.
    Wobei: wo ist eigentlich definiert, dass ein abgebrochener SQL ggf. Teildaten geändert haben könnte?
    Muss ich einen Rollback machen oder kann ich auch einen Commit machen, da es teilgeänderte Daten nicht gibt?

    Spekulation hilft hier nicht.
    Die Frage ist hier eigentlich: Was will der Fragesteller mit dem Timeout denn erreichen?
    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

  7. #7
    Registriert seit
    Mar 2002
    Beiträge
    5.286
    Zitat Zitat von Fuerchau Beitrag anzeigen
    wenn wie meistens ohne Journal gearbeitet wird
    ... das würde ja heißen, dass meistens Murks programmiert wird. Wer updates ohne Commit-Steuerung über SQL macht, gehört über die Planke gejagt, das funktioniert ja in ganz elementaren Fällen schon nicht, wenn die Datenbank von mehreren benutzt wird.

    Mit Commit Steuerung ist das mit dem Timeout doch ganz einfach: schlägt ein Timeout zu, bekommt man in jedem Fall einen neagtiven SQL Code und sorgt dafür, dass Rollback erfolgt.

    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/

  8. #8
    Registriert seit
    Aug 2003
    Beiträge
    1.508

  9. #9
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    Neiiin.
    Dieter und ich überlegen halt gerne wie wir das Forum vollquatschen können.
    In manchen Punkten unterscheiden wir uns in den Meinungen was aber, denke ich, keine Diskrepanz in der Qualifikation ist.

    Die Frage des Timeouts ist ggf. wirklich ein Problem.
    Mache ich einen "insert ... select ...", kann dieser bei einer großen Tabelle durchaus mal mehrere Minuten dauern. Habe ich nun einen Default-Timeout von 30 Sekunden, würde dieser SQL grundsätzlich abbrechen.
    Auf der AS/400 wird aber nur die Select-Phase auf potentiellen Timeout vor dem 1. Satz geprüft. Der eigentliche SQL darf dann durchaus ewig dauern.
    Bei anderen DB's mag das unterschiedlich gehandelt werden.
    Wobei ich hier bei einem SQL-Server durchaus bei einem Update von 100.000 Sätzen schon mal 10-15 Minuten gewartet habe. Ein Timeout hat da nicht zugeschlagen.

    Deswegen noch mal die Frage von vorhin:
    Bei welchem SQL ist denn ein Timout gefragt?
    Ist es tatsächlich nur der "Select", dann wäre der Querytimeout eigentlich ausreichend, da ich mittels Resultset (Reader) ja dann selber bestimme, wie lange ich denn nun Daten empfangen will.

    Ansonsten heißt ja "Query-Timeout" eigentlich wirklich "Select"-Timeout.
    Wobei beim ADODB.Command das wieder "CommandTimeout" heißt und wir wieder beim Update/Delete sind.

    Ach ja: Der Querytimeout zieht auch beim SQL-CALL. Zumindest konnte ich das schon mal feststellen, da mein SQL-Wrapper auf OPM-Programme da schon mal gecancelt wurde.
    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

  10. #10
    Registriert seit
    Mar 2002
    Beiträge
    5.286
    ... auf die Gefahr eines weiteren unqualifizierten Zwischenrufs (was kümmert es die deutsche Eiche, wenn sich eine Wildsau an ihr schubbert...):
    Der QAQQINI Timeout ist ja eigentlich Quatsch!!! Einerseits haut der mir ein Query runter, das locker fertig geworden wäre und kann trotzdem nicht verhindern, dass ich das warten auf ein Ergebnis nicht von einer gestorbenen Connection unterscheiden kann...
    Die Anforderung für einen Timeout ist in einer remote Verbindung essentiell, da dies die einzige Möglichkeit ist unauflösbare Verklemmungen zu vermeiden und da hilft ein a priori Mechanismus (selbst wenn er funktionieren würde) nichts.

    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
    Feb 2001
    Beiträge
    20.207
    Ist ja auch akzeptiert.
    Wenn ich bei ODBC mit ADODB den Querytimeout (Commandtimeout) setze überschreibt er auch den QAQQINI-Wert. Denn gerade wegen der Fehleinschätzungen hat so mancher im System *NOMAX stehen und dann wartet man schon mal länger.
    Beim AS/400-ODBC-Treiber wird die Cancel-Methode unterstützt. Wenn da mal eine Abfrage etwas länger dauert (vor dem 1. Satz!), dann kann man bei asynchronen Queries den Cancel aufrufen und der SQL wird tatsächlich abgewürgt.
    Dies geht wirklich nur durch die Asynchron-Unterstützung des Command-Objektes.
    Ob es das beim JDBC auch gibt kann ich nicht sagen.
    JDBC wird gegenüber OLEDB/ODBC leider gerne vernachlässigt.
    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

  12. #12
    Registriert seit
    Mar 2002
    Beiträge
    5.286
    ... ein Statement hat auch eine cancel() Methode, die PTF Beschreibung von dem timeout sieht aber so aus, dass das der Server auch erst ab V7R1 + PTF kann.
    Hier sei aber am Rande vermerkt, dass dann bei einem Bulk Statement ohne commit die Lage komplizierter ist, als beim Timeout.

    Zweite Randbemerkung: Bulk Statements könnten auch mittendrin abbrechen und auch das kann ohne Commit bereits fatal sein (z. B.: update preise set VKBRUTTO = VKBRUTTO * 1,1 where Warengruppe = 123 bricht irgendwo ab wg. einem gesperrten Satz)

    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/

Similar Threads

  1. sqlpkg via JDBC und Berechtigung
    By Robi in forum IBM i Hauptforum
    Antworten: 4
    Letzter Beitrag: 09-03-16, 10:32
  2. Satzformat in Query in Query angeben?
    By JonnyRico in forum IBM i Hauptforum
    Antworten: 2
    Letzter Beitrag: 31-03-03, 17:21
  3. DB/400 Verbindung via JDBC
    By Jacko in forum IBM i Hauptforum
    Antworten: 7
    Letzter Beitrag: 05-06-02, 11:50
  4. JDBC und Sicherheit
    By sufukli in forum IBM i Hauptforum
    Antworten: 1
    Letzter Beitrag: 24-01-02, 17:31
  5. Zugriff auf DB/400 über JDBC
    By Rucker in forum IBM i Hauptforum
    Antworten: 2
    Letzter Beitrag: 29-09-01, 12:16

Berechtigungen

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