-
Zitat von Fuerchau
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
-
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
-
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.
-
... 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
-
Hallo Zusammen,
dieser Post ist zwar schon etwas älter, aber ich habe im Moment ein ähnliches Problem im Bezug auf 'TimeOuts'. Bei mir geht es jedoch nicht um ein Query TimeOut, sondern um eines beim Verbindungsversuch zur fernen DB. Folgendes Szenario liegt aktuell vor:
- Verbindung via SQL: "connect to DB user User1 using "ABC""
Ist die Verbindung vorhanden, gibt es kein Problem.
Kann die DB jedoch nicht erreicht werden, wartet der entsprechende Job ewig auf eine Antwort.
Die DB ist unter 'WRKRDBDIRE' mit *ARDPGM eingetragen.
Zur Verbindung wird die Bibliothek bzw. die Programme JVAGATE von Dieter Bender verwendet.
Habe mal in den Quellen geschaut und dort auch einen TimeOut Parameter gefunden.
Dieser lässt sich meiner Ansicht nach aber von außen nicht steuern.
@BenderD
Habe ich da vllt etwas in deinem Programm übersehen?
Gibt es generell eine andere Möglichkeit einen TimeOut einzustellen?
Danke vorab!
Gruß
DerMuller
-
Timeout beim Connect ist zuallererst Aufgabe des JDBC Treibers, der zur Verbindung an die remote Datenbank verwendet wird. Einstellbar ist das (falls der Treiber das unterstützt) per Connect String (oder per konfiguration zusätzlicher Parameter).
Der Timeout beim ArdGate wirkt nur, wenn der native Part neu genug ist; ist allerdings nicht unbedingt sauber (wenn dann doch noch Antworten vom Server kommen, kann das asynchron werden - mit krummen Effekten)
einstellbar ist der in global.properties
as400.timeout=xxx
wobei xxx = Anzahl sec. im default steht da -1 (entspricht warte bis Du schwarz wirst)
D*B
Similar Threads
-
By Robi in forum IBM i Hauptforum
Antworten: 4
Letzter Beitrag: 09-03-16, 09:32
-
By JonnyRico in forum IBM i Hauptforum
Antworten: 2
Letzter Beitrag: 31-03-03, 16:21
-
By Jacko in forum IBM i Hauptforum
Antworten: 7
Letzter Beitrag: 05-06-02, 10:50
-
By sufukli in forum IBM i Hauptforum
Antworten: 1
Letzter Beitrag: 24-01-02, 16:31
-
By Rucker in forum IBM i Hauptforum
Antworten: 2
Letzter Beitrag: 29-09-01, 11:16
Berechtigungen
- Neue Themen erstellen: Nein
- Themen beantworten: Nein
- You may not post attachments
- You may not edit your posts
-
Foren-Regeln
|
Erweiterte Foren Suche
Google Foren Suche
Forum & Artikel Update eMail
AS/400 / IBM i
Server Expert Gruppen
Unternehmens IT
|
Kategorien online Artikel
- Big Data, Analytics, BI, MIS
- Cloud, Social Media, Devices
- DMS, Archivierung, Druck
- ERP + Add-ons, Business Software
- Hochverfügbarkeit
- Human Resources, Personal
- IBM Announcements
- IT-Karikaturen
- Leitartikel
- Load`n`go
- Messen, Veranstaltungen
- NEWSolutions Dossiers
- Programmierung
- Security
- Software Development + Change Mgmt.
- Solutions & Provider
- Speicher – Storage
- Strategische Berichte
- Systemmanagement
- Tools, Hot-Tips
Auf dem Laufenden bleiben
|
Bookmarks