Java, пул соединений JDBC, откат соединения JDBC

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

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

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

Нет такого понятия, как откат соединения. Возможно, вы имели в виду откат транзакции. Вы никогда не должны выполнять откат, если вы не собираетесь потерять какие-либо изменения, сделанные в базе данных в транзакции, и вы никогда не должны фиксировать, если вы не собираетесь фиксировать все изменения, сделанные в транзакции.

Сказав это, я не понимаю термин «сначала мы делаем упреждающий откат соединения, чтобы избежать исключений соединения» и почему вы должны делать это в первую очередь. Предполагая, что вы имеете в виду вызов метода Connection.rollback(), я бы посчитал это плохой практикой. На самом деле это приведет к потере производительности, так как требует сетевого вызова и заставляет базу данных отбросить состояние связанной транзакции (что в этом сценарии бессмысленно, так как еще не было выполнено никакой работы).

Если вы намерены избежать исключений, связанных с мертвым соединением, полученным из пула соединений, вы должны настроить пул для проверки того, не устарело ли соединение (обычно путем выполнения тестовой инструкции SQL), прежде чем возвращать соединение в приложение. После того, как приложение установило соединение, оно не должно поддерживать соединение после того, как оно ему больше не нужно; в идеале приложение должно возвращать соединение с пулом. Если вы обнаружите, что держите объект подключения, базовое физическое соединение недоступно для использования другими запросами, и оно может быть фактически закрыто брандмауэром, настроенным на закрытие соединений, которые были активны после определенного периода времени.

Полностью согласен с мана.

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

Пожалуйста, взгляните на логику пула соединений JBoss или просто используйте пакет пула соединений производственного уровня.

Существует обсуждение в Параметры объединения соединений с JDBC: DBCP vs C3P0

Надлежащий способ проверки соединения, исходящего из пула, — использовать проверочный запрос< /а>. Если откат вызван тем, что кто-то опасается, что в пул может быть возвращено «грязное» соединение, вам необходимо использовать реальная структура управления ресурсами.