Понимание JPA и EJB3 и веб-сервисов - PullRequest
2 голосов
/ 18 февраля 2010

Я только начинаю работать с JPA, создавая сессионные компоненты без сохранения состояния из сущностей JPA, а затем получаю доступ к bean-компонентам через веб-сервис. Хотя у меня большой опыт разработки веб-сервисов на основе баз данных «по старинке», у меня есть несколько вопросов о том, что происходит за кулисами с этим новым «подходом, основанным на аннотациях».

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

  1. Создание корпоративного приложения с модулями EJB и веб-приложений.
  2. Создание классов сущностей. Я создал мой из существующей базы данных.
  3. Создание сессионных компонентов из класса сущностей.
  4. Создание веб-служб из сессионного компонента.

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

  1. Я вижу, что веб-служба (созданная с аннотацией @WebService) ссылается на мой сессионный компонент без сохранения состояния (используя ссылку @EJB).
    • Что здесь происходит? Это просто захватывает экземпляр EJB из пула EJB сервера приложений?
      Nevermind. Я думал об экземпляре, в котором было более 1 таблицы, то есть более 1 типа класса Entity и более 1 типа EJB. Я смотрел на веб-сервис и просто видел ссылку @EJB и не понимал, кто получает тип бина из этой аннотации. Чуть ниже, однако, это ссылка на локальный интерфейс бина - вот и все.
    • Если на сервере развернуто более одного типа EJB, как он узнает, какой захватить?
  2. EJB определяется с помощью аннотаций @Stateless и @Local. Реализация компонента ссылается на EnityManager через аннотацию @PersistenceContext.
    • Где выполняется поиск jndi в базе данных (возможно, в файле persistence.xml)?
    • Все ли EJB имеют общий EntityManager (при условии, что EntityManager является потокобезопасным)? Если нет, я знаю, что EnityManager использует кэш второго уровня, чтобы помочь уменьшить количество обращений к базе данных. Эти кеши как-то синхронизированы?

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

Заранее спасибо!

1 Ответ

4 голосов
/ 18 февраля 2010

Что здесь происходит? Это просто захватывает экземпляр EJB из пула EJB сервера приложений?

Конечная точка веб-компонента JAX-WS (в отличие от конечной точки EJB JAX-WS) следует типичной модели потоков сервлета, что означает, что обычно существует один экземпляр, который выполняется одновременно для каждый клиент. Реализации JAX-WS могут свободно использовать пулы экземпляров bean-компонентов для обработки запроса аналогично EJB-компонентам сеансов без сохранения состояния. (источник: Разработка приложений для Java TM Платформа EE FJ-310).

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

Если на сервере развернуто более 1 EJB, как он узнает, какой из них получить?

Хмм ... я этого не понял. Можете ли вы уточнить, что именно вы имеете в виду? С какой стати двусмысленность?

Где выполняется поиск jndi в базе данных (возможно, в файле persistence.xml)?

В среде Java EE источник данных указывается в элементе <jta-data-source> в каждой единице сохраняемости файла persistence.xml (которая может содержать несколько единиц постоянства), а источник данных будет получен с помощью EntityManager (только при необходимости, т.е. только если действительно необходим доступ к данным).

Все ли EJB имеют общий EntityManager?

Нет. EntityManager - это не потокобезопасный объект, который следует использовать один раз для одного бизнес-процесса, одной единицы работы и затем отбрасывать. В среде Java EE, использующей EJB 3, шаблоном по умолчанию является «entitymanager-per-request». Запрос от клиента отправляется на уровень персистентности EJB 3, открывается новый EntityManager, и все операции с базой данных выполняются в этой единице работы. Когда работа завершена (и ответ для клиента подготовлен), контекст постоянства сбрасывается и закрывается, а также объект диспетчера сущностей. (источник: Глава 4. Транзакции и параллелизм ).

...