Сколько соединений JDBC в Java?

Для этого вам следует использовать пул соединений.

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

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

Таким образом, вы можете каким-то образом оставить свое приложение таким, какое оно есть (и не передавать соединение со всех сторон), и при этом правильно использовать ресурсы.

К сожалению, пулы соединений первого класса не очень просты в использовании в автономных приложениях (они используются по умолчанию на серверах приложений). Вероятно, микроконтейнер (например, Sping) или хороший фреймворк (например, Hibernate) могут позволить вам его использовать.

Однако их несложно запрограммировать с нуля.

:)

Этот поиск Google поможет вам узнать больше о том, как его использовать.

Пролистать

Вы можете либо передать соединение, либо еще лучше использовать что-то вроде Jakarta Database Connection Pooling. http://commons.apache.org/dbcp/

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

• предположите, сколько одновременных подключений ваша база данных может разумно обрабатывать (например, начните с 2 или 3 на процессор на машине базы данных, пока не обнаружите, что их слишком мало или слишком много - это будет зависеть от того, как диск -связанные ваши запросы)
• создать бассейн из этого количества соединений: по сути, класс, который вы можете запросить «следующее бесплатное соединение» в начале каждого метода, а затем «передать обратно» пулу в конце каждого метода
• ваш метод getFreeConnection () должен возвращать бесплатное соединение, если оно доступно, иначе либо (1) создайте новое, до максимального количества подключений, которое вы решили разрешить, либо (2) если максимальное количество уже создано , подождите, пока один станет свободным
• Я бы порекомендовал класс Semaphore для управления соединениями; У меня на самом деле есть небольшая статья на моем веб-сайте по управление пулом ресурсов с помощью семафора с примером, который, я думаю, вы могли бы приспособить к своей цели.

Пара практических соображений:

• Для оптимальной производительности нужно быть осторожным не "перебивать" соединение, пока вы на самом деле не используете его для выполнения запроса. Если вы берете соединение из пула один раз, а затем передаете его различным методам, вам нужно убедиться, что вы не делаете это случайно.
• Не забудьте вернуть свои соединения в пул! (попробуй / наконец-то здесь твой друг ...)
• Во многих системах вы не может держать связи открытыми "вечно": операционная система закроет их через некоторое максимальное время. Таким образом, в вашем методе «вернуть соединение с пулом» вам нужно подумать о «уходящие на пенсию» связи, которые существуют уже давно (встроить некоторый механизм для запоминания, например, имея объект-оболочка вокруг фактического объекта соединения JDBC, который вы можете использовать для хранения таких показателей )
• Вы можете рассмотреть возможность использования подготовленных операторов.
• Со временем вам, вероятно, понадобится настроить размер пула соединений

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

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

Обычно объекты ниже «Соединение» не могут безопасно использоваться из нескольких потоков, поэтому обычно не рекомендуется совместно использовать ResultSet, объекты Statement и т. д. Между потоками - безусловно, лучшая политика - использовать их в том же потоке, который их создал; это обычно легко, потому что эти объекты обычно не хранятся слишком долго.

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

Другой подход к пулам соединений -

• Одно соединение для всего доступа к базе данных с синхронизированным доступом. Это не допускает параллелизма, но очень просто.
• Сохраните соединения в переменной ThreadLocal (переопределите initialValue ()). Это хорошо работает, если имеется небольшое фиксированное количество потоков.

В противном случае я бы предложил использовать пул соединений.