Должен ли ServiceLocator искать имя jndi для источника данных?

Question

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

Процесс, выполняющийся в отдельном потоке, должен получить и закрыть собственное соединение. Веб-приложения обычно ищут имя jndi источника данных, используя ServiceLocator, который, в свою очередь, ищет его в контексте приложения (ключ поиска для имени jndi определяется как константа класса), но для отдельного потока, ищущего имя jndi с помощью ServiceLocator выходит из строя. Чтобы обойти эту проблему, мы вместо этого использовали имя jndi в качестве константы класса, чтобы поток мог напрямую искать источник данных.

Это означает, что имя jndi для источника данных теперь фиксировано для приложения, и мы больше не можем развертывать одно и то же приложение в одном и том же контейнере, но с другими источниками данных, просто изменив файл web.xml.

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

Answer 1

Для лучших практик, Роль JNDI в J2EE (в соавторстве с Кирком Пеппердином) - одна из лучших статей, которые я нашел. Это ясно объясняет «видение» Sun относительно разработки, упаковки, развертывания и того, как JNDI вписывается туда.

Короткая версия заключается в том, что поставщики Sun и серверов приложений предоставляют способ определения и имени глобального ресурса (java: DefaultDS) и привязки локального имени ссылки на ресурс (jdbc / mydatasource) к указанному ресурсу.

Это решает проблему переносимости приложения (созданного из компонентов J2EE). Но имя ссылки на локальный ресурс зависит от компонента, поэтому оно не решает вашу проблему (которая развертывает один и тот же компонент несколько раз, но с другим именем ссылки на локальный ресурс).

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

Программный подход, который вы описываете (выполнение поиска значения по ключу, хранящемуся в JDNI / properties / что угодно), является обходным путем.

Answer 2

Да, я чувствую твою боль.

Я думаю, что это очень хорошая идея - попытаться настроить jndi через web.xml. То, как я справился с этим, кэшируется ссылка на источник данных. iow, при запуске веб-приложения источник данных, на который ссылаются, получает доступ, пока он доступен для потока, а затем передается или становится доступным для любого другого объекта, который в этом нуждается.

Answer 3

Вы можете передать имя JNDI или источник данных в качестве аргумента конструктора или метода класса потока.