Session Bean

[Balaji Anand]

hi
Can someone tell me what exactly happens in a sequential order when a session bean is created?
I know the constructor setSessionContext and ejbCreate are called in this order but what happens in those methods? When does the bean get to know abt the client and how?
Also like when will be the bean in meaningful transaction and what that means ?

Thanks

[Peer Reynders]

For the gory details see the EJB 2.0 specification; in particular
7.6.1 Operations allowed in the methods of a stateful session bean class
Table 2.
page 80

7.8.2 Operations allowed in the methods of a stateless session bean class
Table 3
page 90

A stateless session bean cannot "see" information regarding the client until its inside a business method - the container creates and destroys stateless session beans at will - and every business method invocation may come from a different client.

A stateful session bean is dedicated to a client and created in response to an invocation of a create method on the home interface - so it can "see" client specific information as soon as it can talk to the container through the SessionContext - which it receives in setSessionContext.

[Balaji Anand]

thanks Peer Reynders for the reply. I have just started preparing for the SCBCD. so my question may be very simple.
1. how come the table says "CMT" and "BMT" for the session bean? isnt it something related to the Entity Bean? What do i have to know to understand this?
2. When the session context is got in the setSessionContext method, why the table says i cant get the client information and ref of the EJB Object etc. ( Stateless Session Bean)

Thanks for your time and efforts.

[Ramakrishnan Viswanathan]

2. When the session context is got in the setSessionContext method, why the table says i cant get the client information and ref of the EJB Object etc. ( Stateless Session Bean)

For a stateless session bean, the bean creation activity (creating new session context, running bean constructor, calling setSessionContext(), calling ejbCreate) happens at a completely different timeline from a client's business method call. As Peer Reynders mentioned, the container decides when to create the stateless beans in the pool.

Until a business method is called by the client, the bean cannot "see" any client related information - remember, when setSessionContext() is called, there is no client and no EJBObject! - which explains why you cannot get client information and EJB Obj ref in setSessionContext().

[Peer Reynders]

Originally posted by Srividhya Anand:
1. how come the table says "CMT" and "BMT" for the session bean? isnt it something related to the Entity Bean? What do i have to know to understand this?

CMT stands for Container Managed Transaction.
BMT stands for Bean Managed Transaction.

You are confusing them with

CMP Container Managed Persistence and BMP Bean Managed Persistence.

The exam only covers CMP Entity Beans, not BMP Entity Beans.

An Entity Bean can only use CMT, while the others can use BMT. Once you decide to use CMT you can specify transaction attributes like Mandatory, Required, RequiresNew, NotSupported, Never, and Supported. In the case of a CMT Bean you are allowed to use setRollbackOnly() and getRollbackOnly() methods of EJBContext.

For BMT beans you would use EJBContext.getUserTransaction() to obtain a javax.transaction.UserTransaction instance and then use the UserTransaction.getStatus() and UserTransaction.setRollbackOnly() methods.

Also a stateful CMT session bean may implement the javax.ejb.SessionSynchronization interface.

[Balaji Anand]

i am sorry actually my second question shd be..
When the session context is got in the setSessionContext method, why the table says i can not get the client information and ref of the EJB Object etc. ( Stateful Session Bean) in the setSessionContext() method?

[Peer Reynders]

Originally posted by Srividhya Anand:
When the session context is got in the setSessionContext method, why the table says i can not get the client information and ref of the EJB Object etc. (Stateful Session Bean) in the setSessionContext() method?

Interesting question.
If look at Table 2 (page 80), Table 3 (page 90), Table 10 (page 257), Table 12 (page 320 MDB doesn't have home or component interface) - you'll notice that the restrictions are consistent across all types.

In the case of the stateful session bean this allows the Server/Container provider to actually create some bean instances ahead of time, and complete the constructor and the setSessionContext methods before a client request their creation.

That way some potentially time consuming JNDI lookups can be done ahead of time (without the client context) - making the stateless session creation from the client end seem faster.

I think the specification writers reasoned that there is nothing client specific that you could do in the setEntityContext() method that wouldn't be better accomplished in the ejbCreate - so there was no need to constraint the vendors unnecessarily.

[Balaji Anand]

Originally posted by Peer Reynders:



In the case of the stateful session bean this allows the Server/Container provider to actually create some bean instances ahead of time, and complete the constructor and the setSessionContext methods before a client request their creation.

I think the specification writers reasoned that there is nothing client specific that you could do in the setEntityContext() method that wouldn't be better accomplished in the ejbCreate - so there was no need to constraint the vendors unnecessarily.

Did u mean Stateless Session bean or stateful session bean here? if Stateful, doesnt the container create the bean only on the create call from the client?

yes the result is consistent for all the bean types, so from my view they have constained the vendors not to let them use what they have? am i correct?

Thanks for your time and efforts again
[ October 17, 2005: Message edited by: Srividhya Anand ]

[Peer Reynders]

Originally posted by Srividhya Anand:
if Stateful, doesnt the container create the bean only on the create call from the client?

Conceptually you are correct, but by denying the bean provider access to the client specific functions (which Table 3 clearly does) during the setSessionContext() method the specification creates the opportunity for the vendor to fashion a "creation pipeline" with some instances of the stateful session bean that have already completed their setSessionContext() method. When the client invokes a create() method the container can then (more quickly) continue on with the ejbCreate method.

It makes no difference to the client/bean provider whether setSessionContext() runs before or after the client invokes a create() method (as the bean provider isn't allowed to access the client specific functionality in the setSessionContext() anyway).