... 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