View Full Version : 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
Laut Dokumentation sollte es funktionieren:
http://www.ibm.com/support/knowledgecenter/ssw_i5_54/rzahh/javadoc/com/ibm/as400/access/AS400JDBCStatement.html%23setQueryTimeout%28int%29
... 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
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.
... 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
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?
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
andreaspr@aon.at
11-04-16, 13:07
Ist das wieder ein Battle, wer das letzte Wort hat??
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.
... 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