Stateless Session Beans
Some writers postulate that any sufficiently advanced technology appears magical to those not capable of understanding it. Much of the magic can be taken away by simple explanations, and that's what this tip does. Excerpted from a lengthy article on
Got an EJB tip of your own? Why not send it in? You'll garner instant fame as we post it on our site, and we'll enter you in our tips contest for some great prizes.
Session beans are EJB components designed to perform some action on an enterprise system on behalf of the client. Session beans are often designed to serve as the entry points or "frontline" EJBs for EJB clients. EJB clients interact with session beans to obtain the functional behavior and services of the enterprise system that the clients want to utilize.
Stateless session beans are session beans that are designed to not require the preservation of state within the EJB that is specific to a particular EJB client. This does not imply that the EJB does not actually maintain any state within its fields or associated objects. However, it does imply that the state it maintains is not required to be accessed or utilized for a specific EJB client later. This also implies that the state is not important for access by another client later.
Such a designation gives an EJB container some flexibility in maximizing the efficient management of such EJBs. Because using stateless session bean components implies that any of their instances created by the container can be used by any client at any time, the container can maintain a pool of such instances that are allocated to clients on an as-needed basis without regard to which instance belongs to which client. Containers can also easily create and destroy bean instances as needed, to adjust for scalability and resource demands. Thus, although stateless session beans can have state, no assumptions are to be made by the programmer about the validity of that state between successive uses of the bean instance. EJB containers may create stateless session beans, destroy stateless session beans, and allocate stateless session beans for use as they please.
The setSessionContext() method defined on a stateless session bean is used to pass an instance of a SessionContext object to the EJB. It is also the first method defined in the SessionBean interface that is called by the container. A SessionContext object encapsulates an interface to the EJB session container context.
A key operation required by a custom stateless session bean, such as MyStatelessSessionEJBean, but not defined within the SessionBean interface is the ejbCreate() method. A single ejbCreate() method must be defined on stateless session bean implementations with a void return type. This method is called by the EJB container when the container decides to create an instance of the stateless session EJB. The container may decide to do this when it wants to create an initial pool of bean instances, or it may do this when it receives a client's request. The ejbCreate() method is thus akin to a special type of constructor or initialization method implemented by EJBs.
The ejbRemove() method is called by a container on a session bean object when the container is about to decommission the bean instance from handling any more client requests. For stateless session beans, the container is solely responsible for determining when it will call ejbRemove() on a particular session bean instance. It is not bound in any way to the EJB client.
Because no assumptions are made about the importance of state in a stateless session bean, there is no assumed need to passivate and activate stateless session beans. That is, containers do not assume that a stateless session bean must close any open resources when it is to be removed from active memory (that is, passivated) and do not need to re-create any connections to open resources when brought back into active memory from persistent memory (that is, activated). Thus, the implementations for ejbPassivate() and ejbActivate() methods for stateless session beans are often simple empty implementations.
To read this entire tip, click over to InformIT. You have to register there, but the registration is free.
Did you like this tip? You can let us know via email.
This was first published in October 2001