Verbindung zur Datenbank bricht ab

[BenderD]

... typische TCP/IP Timeouts liegen im Bereich von > 5 Minuten bis zu einer Stunde. Wenn eine SQL Anforderung in der Zeit noch nix zurückbringt, ist das für mich ein Designfehler, auch wenn solcher Unfug gerne in stored Procedures reinprogrammiert wird (Sticjhwort: Rückgabe Array statt offener Cursor). Wenn ein SQL Statemnet da nix zurückbringt, fehlt es an einem Index.
Wenn eine Transaktion länger als ein paar Sekunden nix von der Datenbank will, liegt meist ebenfalls ein Designfehler vor (Stichwort: dem Benutzer innerhalb einer Transaktion die Kontrolle geben).
Keep alive checks eines ordentlichen Pools lassen sich konfigurieren, üblich ist da eine relativ billige Abfrage; stellt man nun den entsprechenden Schwellenwert kleiner als den TCP Timeout, wird bei Bedarf automatisch reconnected.
Was Ooops Nerv angeht, der hält die Connection offen, weil er keinen Pool kann (hier haben wir den Murks!!!), wenn ich hier länger nix gemacht habe, muss ich per Hand reconnecten, oder renne auf den Hammer.

Folgerungen:
- ordentliches Werkzeug statt Spielzeug verwenden
- Schluss mit dem Missbrauch von stored-Procedures (meistens ist das Stuss!!!)
- in Applikationen pro Transaction eine frische Connection vom Pool holen
- Datenbanktransaktionen dürfen Benutzertransaktionen nicht überlappen

D*B

[Fuerchau]

"- Schluss mit dem Missbrauch von stored-Procedures (meistens ist das Stuss!!!)
":
Sag das mal der IBM, die Schema-Abfragen per ODBC auch auf stored Procedures umgestellt haben, was nun ab und zu zu Query-Timeouts selbst auf leere Dateien führt, da die stored Procedure leider zu lange benötigt um Spalteninformationen aus der SYSCOLUMNS (mehrere Millionen Sätze) abzurufen (V7R1!).

ODBC-Anwendungen sollten natürlich immer mit Verbindungsabbrüchen und einem (Auto)Reconnect zurecht kommen.

Bei 5250-Anwendungen ist das eher lässtig.
Der Timeout bewegt sich aber häufig im Default bei 2 Stunden.
Hier könnte man halt auf der AS/400 die Inaktivitätszeiten nutzen und bei einer Inaktivität von 90 Minuten die Sitzung disconnecten (DSCJOB).
Bei der erneuten Anmeldung wird dann auch korrekt wieder aufgesetzt.

[BenderD]

Sag das mal der IBM, die Schema-Abfragen per ODBC auch auf stored Procedures umgestellt haben, was nun ab und zu zu Query-Timeouts selbst auf leere Dateien führt, da die stored Procedure leider zu lange benötigt um Spalteninformationen aus der SYSCOLUMNS (mehrere Millionen Sätze) abzurufen (V7R1!).

... das ist so ein Fall von Dummfug, der dummfugigsten Sorte