Использование JNDI для подключения к базе данных

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

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

И учебник использует источник данных JNDI.

Мое приложение также похоже(но я не буду использовать Tomcat, только сокеты), и мой сервер будет получать запросы от нескольких клиентов, но я не понимаю, почему я должен использовать источник данных JNDI, почему сервер не может поддерживать одно открытое соединение с базой данных, и когда клиентский запрос поступает, он обрабатывает запрос и передает данные клиенту.

В худшем случае, если мне понадобится JNDI, как я могу реализовать его с моим сервером приложение?

4 4
jdbc database jndi

4 ответа:

Таким образом, это клиентское приложение? Приложение и база данных обычно разговаривают друг с другом, используя соединение, полученное с помощью DriverManager#getConnection()? Если это так, то вам не обязательно нужен JNDI, чтобы получить пул соединений для работы. Одной только структуры объединения соединений, о которой идет речь, уже было бы достаточно. Например C3P0 или Apache Commons DBCP (я бы рекомендовал C3P0; DBCP является однопоточным). Просто замените DriverManager#getConnection() на него.

Edit: ответ на ваш комментарии:

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

На самом деле я имею в виду простое ванильное Java-приложение, которое не работает внутри контейнера Java EE. Паскаль сформулировал это лучше.

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

Для запуска пул соединений открывает соединение и удерживает его открытым до заданного времени ожидания. Пул соединений обертывает / украшает соединение своей собственной реализацией. Пул соединений может одновременно открывать и удерживать настроенное количество соединений. Когда вы позвоните getConnection(), он сразу же даст вам уже открытое соединение. Когда вы звоните close() при подключении он вернет соединение в пул для будущих запросов. Это, таким образом, означает, что вам все еще нужно написать код JDBC обычным способом: получить и закрытьConnection, Statement и ResultSet в кратчайшем возможном объеме. Закройте их все в блоке finally. Если ваш код JDBC уже хорошо написан, на самом деле нужно заменить только DriverManager#getConnection(). Поскольку вы должны открывать и закрывать Connection в одном и том же блоке метода, он обычно будет работать в одном и том же блоке. нитка. Пул соединений будет беспокоиться о том, что Connection не будет получен другими потоками в то же время, пока ваш код не вызовет close() на Connection.

Вы можете найти здесь хорошую статью, чтобы получить представление о том, как работает объединение соединений под капотом (будьте осторожны: не используйте его для производства и не выращивайте его дальше, это просто чтобы получить всю идею). Для реальной работы используйте существующую тщательно разработанную и надежную структуру пула соединений.

4

Мое приложение также похоже(но я не буду использовать Tomcat, только сокеты), и мой сервер будет получать запросы от нескольких клиентов, но я не понимаю, почему я должен использовать источник данных JNDI, почему сервер не может поддерживать одно открытое соединение с базой данных, и когда клиентский запрос поступает, он обрабатывает запрос и передает данные клиенту.

Ну, вы могли бы. Но что делать, если у вас несколько клиентов и вам приходится обслуживать параллельные запросы? От конечно, вы можете поддерживать одно соединение открытым для каждого клиента, но это не очень хорошо масштабируется (что может не быть проблемой в вашем контексте). Тем не менее, традиционный способ решить эту проблему-использовать пул соединений (и воспользоваться дополнительными услугами, например проверкой соединения, обновлением соединения) и использовать его для получения соединения "по требованию".

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

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

2

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

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

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

Поскольку ваше приложение является самим сервером, приложение, следовательно, отвечает за определение и управление подключением(соединениями) к базе данных.

2

Выбрасывание другой ссылки в другой пул соединений: BoneCP (http://jolbox.com ). тесты показывают, что это быстрее, чем C3P0/DBCP.

С. П. не видел ГСБД запереть в моей многопоточные тесты.

1