Освобождение соединений из пула соединений

В нашем коде (который запускается как задание по расписанию через таймер) у нас есть потоки, работающие параллельно для выполнения операции с базой данных. Проблема здесь в том, что каждый поток инициирует соединение через фабрику Hibernate. Эти соединения закрываются после каждого действия с базой данных, но по-прежнему сохраняются в пуле соединений (как НЕАКТИВНЫЕ). Все соединения освобождаются только после завершения задания/основного процесса. Есть ли способ освободить соединение даже из пула соединений после операции с базой данных. Когда мы используем задание cron вместо таймера, процесс автоматически завершается, но здесь cron нам не нужен. Пожалуйста, помогите нам решить эту проблему, так как мы уже приближаемся к выпуску продукта. Примечание. Мы узнали об этом, когда QA тестировалась с большой нагрузкой на задании, и для каждой нагрузки подключались новые соединения.


java connection connection-pooling
person Balachandar Thangavel    schedule 19.05.2017    source источник
comment
звучит как утечка соединения, а не пул.   -  person Michael Markidis    schedule 19.05.2017
comment
Мы подозревали то же самое. Но мы прошли код и убедились, что закрыли все соединения. Что происходит, когда мы закрываем соединение, оно возвращается в пул, а не освобождается, и пул освобождается только тогда, когда почтовый поток уничтожается. Итак, можем ли мы освободить пул, фактически не выходя из процесса?   -  person Balachandar Thangavel    schedule 19.05.2017

Ответы (2)


arrow_upward
3
arrow_downward

Вам необходимо ограничить количество потоков, создаваемых в пуле потоков.

dotConnect для Oracle использует пул соединений. Строка подключения OracleConnection имеет параметр Pooling. Если Pooling=true (значение по умолчанию), соединение после закрытия не удаляется, а помещается в пул. Когда открывается новое соединение с той же строкой соединения, оно берется из пула (если есть свободные соединения) вместо создания нового. Это обеспечивает значительное улучшение производительности. Если вы используете 800 подключений, каждое из которых подключается в течение 10-15 секунд, и имеется всего несколько разных строк подключения, у вас может не быть 800 реальных подключений. Закрытые подключения будут помещены в пул, и они будут взяты из пула, когда откроется новое подключение с той же строкой подключения. Никакого дополнительного соединения в этом случае открываться не будет.

Вы можете отключить создание пула, добавив «Pooling=false» в строку подключения. В таком случае соединение будет удалено из памяти и освободится сессия. Однако это может привести к потере производительности.

Скорее всего, объединение не должно приводить к созданию слишком большого количества сессий. Попробуйте протестировать приложение с включенным пулом. Если количество сеансов будет слишком большим, вы можете отключить объединение.

Для получения дополнительной информации см. http://www.devart.com/dotconnect/oracle/docs/FAQ.html#q54

person bhuvan salanke    schedule 19.05.2017
comment
Мы не можем этого сделать, так как это существующий устаревший дизайн, люди не хотят ничего менять сейчас. Любые другие предложения? Например, прерывание потока или его уничтожение приведет к освобождению соединения из пула? когда освобождаются соединения пула? - person Balachandar Thangavel; 19.05.2017
comment
Поток никогда не может быть убит или остановлен. Вам нужно ограничить количество потоков, которые вы создаете. Таким образом, другой вариант - закрыть соединение, когда работа будет выполнена, которую вы уже выполняете. Какую БД вы используете? Проверьте документ, если вы можете ограничить количество подключений, которые могут быть созданы на стороне базы данных, можно контролировать. - person bhuvan salanke; 19.05.2017
comment
Мы используем оракул 11g. да, мы можем ограничить то же самое с помощью размера пула потоков и других параметров. еще одна проблема здесь заключается в том, что фабрика сеансов инициируется каждый раз, когда выполняется вызов базы данных, а не выполняется как синглтон для общего использования в приложении. Кроме того, если я ограничиваю, потоки должны ждать, пока другие потоки не освободят соединение. Таким образом, вы попали в тупик, не зная, как освободить соединения пула. Есть ли возможность вручную разблокировать подключения к пулу? - person Balachandar Thangavel; 19.05.2017
comment
Пожалуйста, обратитесь к ответу - person bhuvan salanke; 19.05.2017
comment
Спасибо @bhuvan. Никогда не пробовал с концепцией объединения как ложной. Насколько мне известно, Oracle реализует пул по умолчанию, если мы ничего не указали. позвольте мне попробовать с пулом как ложным, поскольку у нас большая нагрузка. Будет держать в курсе.!! Большое спасибо ! - person Balachandar Thangavel; 19.05.2017
comment
отключил настройки пула, и теперь мы можем сохранить значительное количество подключений .... Можно увидеть, что количество подключений в v$session в этом случае уменьшается до большего количества ... Большое спасибо за предложение !! :) - person Balachandar Thangavel; 19.05.2017
comment
ой!!!! пропустил основной журнал ...! Он выдал ошибку при закрытом соединении для выполнения оператора! - person Balachandar Thangavel; 19.05.2017
comment
Бхуван .. исправил это .. это была глупая ошибка .. Я нашел промежуточное решение. Я уменьшил минимальное и максимальное соединение, а также тайм-аут для освобождения соединения из пула до 1 ..... Это помогло мне получить соединения в стабильном количестве. Теперь мы преломили код в некоторых местах, чтобы использовать общую фабрику сеансов .... это значительно уменьшило количество подключений! Большое спасибо за ваши предложения ... мы еще не проверили его полностью .... :) - person Balachandar Thangavel; 24.05.2017

arrow_upward
0
arrow_downward

Я нашел основную причину проблемы, а также нашел решение. Основной причиной было количество подключений, установленных как минимальное и максимальное, и параметр тайм-аута. Минимум 5, максимум 20 и время ожидания 800 секунд. Но наша работа должна была выполняться каждую минуту. Из-за конфигурации соединения не были должным образом разорваны в течение минуты. Другая проблема заключалась в том, что наш код не использовал фабрику сеансов как синглтон, а инициализировался для каждого потока. Поскольку ресурс не был общим, каждая фабрика сеансов по умолчанию создает 5 подключений и расширяет их до 20 макс. Так как тайм-аут также был выше, прежде чем соединения были освобождены, следующий набор заданий запускается и создает свой собственный набор новых соединений. Наконец, пул переполняется, и оракул становится недоступным.

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

person Balachandar Thangavel    schedule 24.05.2017