Java - Orcale не удалось открыть соединение JDBC для транзакции

#java #oracle #tomcat #ojdbc

#java #Oracle #tomcat #ojdbc

Вопрос:

Я работаю над очень, очень большим, но плохо реализованным проектом, и у нас большая проблема с производительностью, связанная с базой данных de. Мы используем Oracle, exadata и bla bla bla. Сервер приложений: tomcat Diver: ojdbc6

И следующие конфигурации:

 <property name="connectionCachingEnabled" value="true" />
<property name="connectionCacheProperties">
<value>
MinLimit:180
MaxLimit:200
InitialLimit:50
ConnectionWaitTimeout:120
InactivityTimeout:180
....

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

Да, я знаю… о чем вы думаете. Когда я прибыл, это уже было так, и мне нужно это исправить, тем временем команда активно работает над реинжинирингом

Проблема в том, что 15 модулей должны принимать 200 подключений, но с помощью этого спагетти каждый из них также использует включенные подключения модулей.

это суп из соединений!

Но на данный момент проблема заключается в том, что некоторые модули не могут принимать свои 200 подключений, потому что в базе данных больше нет ресурсов…. связанный с конфигурацией «ConnectionWaitTimeout», он возвращает пулу красивое значение null со следующим сообщением:

Не удалось открыть соединение JDBC для транзакции; вложенным исключением является java.lang.Исключение IllegalArgumentException: соединение не должно быть нулевым

Проверка в базе данных для большинства модулей требуется 200 подключений, но только 7 активных и 197 неактивных.

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

Я использовал inactivityTimeout и AbandonedConnectionTimeout, но проблема сохраняется.

1. MinLimit:180 звучит так, как будто пул всегда будет открывать не менее 180 соединений (и будет держать их открытыми). Изменяет ли значение, например, 5, что-нибудь?

2. Когда мы изменили его на меньшее значение, результат был тем же

Ответ №1:

Без анализа приложения мы можем просто размышлять о том, почему возникает эта проблема.

Поскольку было создано 197 подключений (более 180), похоже, что приложение запросило так много подключений из пула.
Поскольку неактивное время ожидания не помогло, мы должны предположить, что соединения все еще сохраняются приложением.
Теперь, поскольку время ожидания отмены не помогло, есть 2 возможности.
A) Приложение действительно запрашивает базу данных в течение периода ожидания.
Б) Пул восстановил соединения, приложение должно было перехватить исключение и повторить попытку

Я предлагаю вам понять код в 1 из модулей, чтобы понять шаблон использования соединения.