EJB с сохранением состояния с расширенным контекстом постоянства для обработки пользовательского сеанса - PullRequest
Новая
       20

EJB с сохранением состояния с расширенным контекстом постоянства для обработки пользовательского сеанса

3 голосов
/ 14 июня 2011

Я использую сессионный компонент CDI для хранения информации, относящейся к пользователю (его объектный компонент, учетные данные и т. Д.). У меня есть метод сохранения каждый раз, когда пользователь изменяет свою информацию (например, адрес электронной почты, пароль и т. Д.). Тем не менее, я мог бы иметь сессионный компонент с сохранением состояния с расширенным контекстом постоянства, чтобы сделать это. Если я сделаю это, его пользовательский объект станет управляемым во время его сеанса, и изменения в его электронной почте и т. Д. Будут синхронизированы без воссоздания постоянных контекстов и т. Д. Это хорошая идея? Должен ли я иметь расширенный контекст постоянства, открытый так долго? Это также блокирует изменения пользователя для внешних bean-компонентов, верно? Что делать, если у меня есть администратор, пытающийся внести изменения в этого пользователя (это может произойти).

Ответы [ 2 ]

5 голосов
/ 15 июня 2011

Я использую расширенный контекст персистентности в различных проектах Java EE 6, это сценарий:

  • a " фасад " (sfsb), внедрение служб (s))
  • a " service " вводит EM
  • a " dbproducer " производит EM в область диалога фасада
  • фасад имеет все транзакции отключены по умолчанию (например, loadEntity() не имеет транзакции)
  • некоторые методы фасада явно включают транзакцию (например, saveEntity() имеетпереход)

В результате получается:

  • Объект загружается и остается управляемым в течение всей продолжительности разговора (отлично кэшируется контекстом постоянства, что -при отсутствии транзакции - не будет сбрасываться).
  • Если (и только если, ради примера) сущность сохраняется, транзакция будет явно открыта, а контекст постоянства сбрасывается вдБ, если транзакция прошла успешно.
  • В случаепри любых других изменениях (например, администратором), OptimisticLockingException будет выброшено и обработано приложением

Это работает как шарм, и выглядит довольно элегантно: -)

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

Вы также можете подумать о том, как EM может присоединиться к существующей транзакции (это может легко случиться, если у вас более одного вызова службы на запрос).Если вы не в стеке Seam 3, EM с прокси-сервером является опцией, если вы используете Seam 3, используйте @Unwraps (Solder) вместо @Produces и проверьте, есть ли транзакция, к которой нужно присоединиться.

5 голосов
/ 14 июня 2011

Есть несколько побочных эффектов, о которых вам следует опасаться.

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

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

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

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

Тот факт, что сессионные компоненты Stateful теперь могут быть ограничены с помощью CDI (и, следовательно, автоматически уничтожаются, когда, например, сеанс HTTP уничтожается), делает всю концепцию гораздо более жизнеспособной. Но CDI также является относительно новым, и многие люди все еще должны понять, как его лучше всего использовать.

...