vint15MasterZivЯ думаю, тебе не стоит заморачиваться над решением этой проблемы, просто при перегрузке СУБД нужно сначала выключить твой сервис, потом поднять СУБД, потом включить твой сервис.

У меня требование к отказоустойчивости очень сильное, на сервере может просто выключится питание. Мне хотелось бы как-то в таком случае получить ошибку. И в случае разрыва сети, тоже нужно получать ошибки. Раз все так серьезно, то прочти хотя бы документацию:

setTimeOut()

Set the time-out period, in seconds, for a connection in the connection pool.
This method sets the time-out period for a connection in the connection pool. OCCI will terminate any connections related to this connection pool that have been idle for longer than the time-out period specified.

Это время жизни подключения в пуле, когда оно не используется.

Вероятно, когда подключение в пуле упало, пул начинает перебирать и пытаться восстанавливать подключение до тех пор, пока не найдет живое. Если пул большой, на то может уйти много времени.

Сколько я помню в OCI можно использовать не блокирующий режим. Тогда функция сразу возвращает код "в процессе", и нить может периодически повторять вызов функции, пока та не вернет другой код или когда надоест ждать прервать выполнение методом OCIBreak().

Для блокирующего режима наверное можно создать следящую нить, которая прервет выполнение "зависшей" нити по истечении некоторого таймаута. Насколько я знаю встроенного механизма в OCI нет.

Кроме того таймауты можно установить на уровне TCP/IP. Тоже как то сталкивался со слишком долгим "умиранием" подключение. Оказалось, что на уровне протокола был установлен длительный период ожидания, на предмет, вдруг связь восстановится? И в общем клиент мог долго ждать ответа от сервера, тогда как сетевой кабель был отключен.