SessionSynchronization ?? is HJEJB Wrong or i am lost......

[Chandra Vadlamani]

All,

In HFEJB, the following is mentioned on page 508 that

Session beans using BMT must not implement SessionSynnchronization

on page 513

Stateless session beans can't implement SessionSsynchronization because only stateful session beans can implement sessionsynchronization, because stateless session beans arent allowed to maintain a transaction once a method has ended.

My questions under CMT

how does it matter if a bean is stateless or stateful, DD is the one which governs the scope and the smallest scope is method level.

Any clarifications will be appreciated.

Thanks

[Leena Diwan]

Stateful Session Bean with CMT can implement SessionSynchronization interface.

Stateful BMT and Stateless CMT/BMT beans are not allowed to.
[Refer tables number 2 and 3 in the ejb spec]

Originally posted by Chandra Vadlamani:
how does it matter if a bean is stateless or stateful, DD is the one which governs the scope and the smallest scope is method level.

There are some session beans which can be deployed as stateful or stateless. But not all. Like if there is a session bean which has create() methods with arguments, there is no chance that this bean can be deployed as a stateless session bean.

The choice of whether a bean should be a statless OR stateful session bean depends on the business logic and generally a few beans will be in a category where the deployer needs to change the statefulness/statelessness.

In cases in which one is sure that a bean will not be and cannot be deployed as a stateless session bean, SessionSynchronization interface can be implemented, if needed.

Regards,
Leena

[Sun Raj]

Hi,
If that is the case then what is the point in having the switch, to indicate whether it is a sateful or stateless, in the DD?

-SR

[amol deshpande]

Hi there,
a BMT is supposed to handle everything about tx and container will never make any fevers on bean. a bean is all on itself. Like it will never interfere in BMT session bean to give u chances to have callbacks like afterBegin, beforeCompletion, afterCompletion.
this is primarily because in BMT, its bean who manages UserTransaction's begin and other calls. since its bean who manages Tx scoping of methods(stateful session BMT can leave Tx accross methods), Container doesnt know about it. Since container doesnt know about it, it can never know when Tx begun(to call after begin) , when it ended(to call before completion/after completion).

Hence only CMT can have SessionSynchronization.

Why only stateful session can use SessionSynchronization, why not stateless session?

let me have a try...
a stateful session bean stores the conversational state accross methods.But a stateless session bean is not allowed to manage session accross method calls.
afterBegin and beforeCompletion MUST execute in same TX and must carry an attribute Required,RequiresNew or Mandatory....but since stateless session CMT doesnt store conversational state with client accross methods, how can it propagate calls to SessionSynchronization methods??
I think its a pretty good reason why only CMT session stateful only can use SSynz interface.
Amol (husssshhhh ...he he)

[raj guntupalli]

May be before giving the bean the beanness(may be before setting the session context) the container might look into the descriptor file to look what are the necessary services to be provided(if cmt provide transaction support,what type of bean it is etc)so If the container finds its of type stateless then it might do the interface check