ODP.NET: предотвращение тайм-аутов подключения с помощью пула подключений

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

Сводка TL; DR состоит в том, что драйверы ODP.NET и реализация .NET плохо взаимодействуют друг с другом, и поэтому ваш обычный запуск стандартных настроек пула соединений, похоже, не работает точно так, как вы ожидаете.

• Connection Lifetime является основным нарушителем. Я не уверен, что этот блог все еще применим, поскольку он довольно старый, но я еще не нашел никакой документации, чтобы опровергнуть его, и, похоже, он подтверждает поведение, которое я наблюдаю. Согласно блогу, Connection Lifetime убивает старую сессию, как и ожидалось, но проверка этого параметра происходит только при обращении к базе данных. Другими словами, .NET никогда не уничтожит длительные простаивающие сеансы.
• Если в вашем профиле пользователя Oracle для IDLE_TIME установлено значение (а не UNLIMITED), то в конечном итоге эти параметры длительного простоя будут SNIPED базой данных. Это может в конечном итоге вызвать проблемы на стороне .NET, потому что, если вы явно не проверяете, что ваши соединения все еще открыты, .NET будет обслуживать эти SNIPED соединения, как если бы они все еще были доступны (таким образом, возникает указанная выше ошибка ORA тайм-аута).
• Уловка для решения этой проблемы заключается в том, чтобы убедиться, что в строке подключения есть Data Validation=True;. Это гарантирует, что .NET будет проверять возможность подключения к сеансу, прежде чем обслуживать подключение до следующего вызова службы. Когда эта проверка видит сеанс SNIPED, она удаляет его из пула соединений .NET.

Учитывая эту информацию, наиболее вероятно, что исходная проблема OP проявлялась только на одном сайте из-за комбинации различных настроек базы данных и / или частоты обращений .NET к базе данных. У него могла быть проблема в обеих средах, но если бы пользователи в одной среде выполняли вызовы достаточно часто, чтобы Connection Lifetime выполнял свою работу, он никогда бы не увидел эти тайм-ауты в этой базе данных.

Я все еще не понял, как убить простаивающее соединение в .NET до того, как произойдет какой-либо снайпер Oracle IDLE_TIME, но пока вы используете этот параметр Data Validation = True, вы, надеюсь, сможете обойти эту проблему.

Если настройка времени жизни 5 минут на первом сайте работает хорошо, то я думаю, что это может быть вызвано тем, что кто-то установил тайм-аут простоя сеанса в профиле на стороне сервера Oracle.

Тем не менее, с настройкой 5-минутного срока службы вы все равно можете достичь тайм-аута, когда ваш рывок станет больше, потому что, когда вы вернете соединения в пул в следующем рывке, они будут уничтожены. Затем пул будет занят созданием и удалением подключений, что может привести к тайм-ауту подключения, когда нагрузка действительно велика.

Вы можете указать бесконечный тайм-аут, установив для свойства OracleCommand.ConnectionTimeout значение 0. В этом случае таймаута не будет (по крайней мере, на стороне клиента).

В этом случае также используется ConnectionPool.