This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
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.
Cheers<br /> <br />What's with the bottom line.<br />_ _ ____________________ _ _<br />SCJP 1.4, SCBCD 1.3, Prepping for SCEA.....
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.
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)
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