Сколько подключений JDBC в Java?

У меня есть Java-программа, состоящая из 15 методов. И эти методы очень часто вызываются при выводе программы. На данный момент я создаю новое соединение в каждом методе и вызывая инструкции для них (база данных настраивается на другой машине в сети).

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

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

Ответ 1

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

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

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

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

Ответ 2

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

Ответ 3

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

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

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

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

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

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

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

Скрыть

Ответ 4

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

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

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

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

Ответ 5

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

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

Как правило, объекты ниже "Connection" не могут безопасно использоваться из нескольких потоков, поэтому обычно не рекомендуется делиться объектами ResultSet, Statement и т.д. между потоками - на самом деле лучшей политикой является их использование в том же потоке, который их создал; это обычно легко, потому что эти объекты обычно не сохраняются слишком долго.