Что такое источник данных и объединение пулов в Tomcat и других контейнерах, связано с JNDI?

Question

Я пытаюсь понять пул соединений (объединение JDBC-соединения). В соответствии с ответом i n this question каждый контейнер имеет свой собственный механизм. Я также пытаюсь понять JNDI и его реализацию и независимо пост или статью там это связанно с размещением объектов в сети, как каталоги и пользователи и здесь некоторые статьи:

http://www.oracle.com/technetwork/java/jndi/index.html http://www.oracle.com/technetwork/java/overview-142035.html

Чтение этой статьи который описывает, как управлять пулы соединений в Tomcat контейнер, второй абзац

javax.sql.DataSource интерфейс зарегистрирован в службе имен на основе JNDI API. Драйвер источника данных позволяет получить доступ к базе данных через интерфейс DataSource. Объект DataSource ищется в контексте, основанный на учет через JNDI ресурсы

Вопрос заключается в том, что JNDI и сетевые каталоги связано с инстанцированием реализации DataSource, который обеспечивает пулы соединений, вероятно, реализуются с помощью конструкции наилегчайшем шаблон ?

Я что-то упустил?

Answer 1

Они не имеют прямого отношения. DataSource - это просто интерфейс для управления соединениями в пуле подключения к базе данных. Любой Java-сервлет-контейнер или Java EE Container может предоставить свою собственную реализацию для этого интерфейса.

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

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

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

Answer 2

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

1. У вас есть приложение Java, и вы хотите подключиться к базе данных и сохранить свои данные. Хорошо, здесь идет JDBC.

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

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

   4. JNDI - Вы пишете свое приложение Java в форме корпоративного приложения, будь то Java EE или его устаревшая альтернативная Spring. И вам нужно как-то творить. Наивный подход заключается в том, чтобы приложение создало собственный источник данных (весной по-прежнему жизнеспособный вариант). Лучшим подходом является настройка источника данных на сервере. Источник данных идентифицируется именем, и приложение указывает только имя - ничего. Затем источник данных вводится в приложение, когда он развертывается на сервере приложений. Конфигурация и создание источника данных выполняется на сервере и вводится в приложение через JNDI. Таким образом, например, у вас может быть больше приложений, использующих один и тот же источник данных с тем же пулом соединений.

Но JNDI не только служат для источника данных "инъекции". С помощью JNDI вы можете идентифицировать и локализовать любые ресурсы.

Answer 3

Иногда JNDI используется как хранилище объектов (объекты Java), а не для доступа к объектам по сети или файловой системе, например принтерам и каталогам, но для доступа к объектам Java, которые уже были созданы в памяти. Путаница, что у меня было связано с тем, что всякий раз, когда вы читаете о JNDI, это объясняет его главная цель не так, как она используется для создания экземпляра DataSource объектов:

Вот это Quot из оракула учебника:

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

http://docs.oracle.com/javase/jndi/tutorial/getStarted/concepts/java.html