Почему сессионный компонент EJB без сохранения состояния не должен реализовывать SessionSynchronization?

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

ОБНОВИТЬ:

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

Контейнер пытается зафиксировать транзакцию после завершения бизнес-метода. Контейнер выполняет протокол фиксации перед отправкой результата метода клиенту.

Согласно учебнику по Java EE 6:

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


java transactions ejb jakarta-ee stateless-session-bean
person Tarik    schedule 07.01.2016    source источник

Ответы (1)


arrow_upward
3
arrow_downward

Вопрос относится к теме транзакций. Поскольку сеансовые компоненты без сохранения состояния (SLSB) не сохраняют состояние диалога между последующими запросами, любые изменения в состоянии ресурсов (например, обновление базы данных) являются локальными в контексте метода. Транзакция не может быть разделена на несколько методов для SLSB.
Ситуация с сессионным компонентом с отслеживанием состояния (SFSB) немного отличается. Это не обязательно для завершения транзакции до завершения метода. Поэтому транзакция может охватывать несколько методов.
Когда вы разрешаете контейнеру управлять транзакциями (CMT) и используете SFSB, есть вероятность, что вы не знаете точно, когда транзакция запущена/завершена. Вам нужен механизм, который уведомляет, когда происходят эти действия. И это SessionSynchronization цель реализации интерфейса.
SLBS с CMT не получают уведомления о начале/конце транзакции, поскольку известны границы транзакции и они ограничены выполнением бизнес-метода.

person slwk    schedule 07.01.2016
comment
спасибо, но это не то, что сказано в спецификациях, не могли бы вы показать мне, что в спецификациях это не обязательно для завершения транзакции до завершения метода? - person Tarik; 07.01.2016
comment
Я не могу показать вам буквально, потому что это мои слова. Однако обратите внимание: в случае сеансового компонента с отслеживанием состояния возможно, что бизнес-метод, который запустил транзакцию, завершается без фиксации или отката транзакции. Это из главы 13.6.1 спецификации EJB 3.1. Взгляните также на диаграмму в главе 4.6. и метод готов в блоке TX. - person slwk; 07.01.2016
comment
Упомянутый вами раздел спецификаций посвящен демаркации транзакций, управляемых компонентами, что не относится к нашему случаю, поскольку вы не можете реализовать SessionSynchronization из BMT. Здесь мы говорим о CMT - person Tarik; 07.01.2016
comment
Но схема касается как CMT, так и BMT. - person slwk; 07.01.2016
comment
Ничто на схеме не связано с этим! Я не понимаю, как вы можете определить границы транзакций на этой диаграмме. - person Tarik; 07.01.2016
comment
Взгляните на afterBegin() beforeCompletion() afterCompletion() методы. И можете ли вы увидеть готовый метод в блоке TX? И изогнутая стрелка к нему прилипла? - person slwk; 07.01.2016
comment
Я нахожусь в спецификациях и видел, о чем вы говорите, но это не значит, что контейнер не будет зафиксирован до возврата метода! он зафиксирует когда тогда?! Я упомянул в своем вопросе четкие предложения из спецификаций, которые контейнер зафиксирует после завершения метода. И это для всех видов сеансовых компонентов CMT. - person Tarik; 07.01.2016
comment
@Tarik Это верно только для REQUIRES_NEW. Для MANDATORY и REQUIRED контейнер EJB зафиксирует транзакцию только в конце метода, если он начал транзакцию, а не только что присоединился к уже существующей транзакции. Теоретически спецификация EJB может позволить сеансовым компонентам без сохранения состояния реализовать SessionSynchronization, но вызывать обратные вызовы только в том случае, если метод компонента запускает транзакцию, но я подозреваю, что этого не произойдет из-за высокой концептуальной сложности. Экземпляр не имеет состояния, поэтому я предполагаю, что ему потребуется доступ к данным из TransactionSynchronizationRegistry? - person Brett Kail; 07.01.2016
comment
Transaction cannot be spanned across multiple methods for SLSB - это неправда. - person Steve C; 08.01.2016
comment
@BrettKail, вы правы, но не могли бы вы подробнее рассказать о TransactionSynchronizationRegistry? - person Tarik; 08.01.2016
comment
@Tarik putResource/getResource позволит SLSB хранить локальное состояние транзакции, не сохраняя его в экземпляре компонента. Таким образом, контейнер может вернуть фактический экземпляр компонента в пул в конце метода, а затем получить новый, когда транзакция наконец завершится, если это не совпадает с окончанием метода. - person Brett Kail; 08.01.2016