Java Reference
In-Depth Information
A session bean represents a single client inside the J2EE server and performs tasks on behalf of the
client. This type of bean manages sessions (or conversations between the client and the server) on
behalf of the client. A typical session is transient, and its state is usually not persistent. An example of a
session is tracking your courier package using a Web-based status-query application. If, for some
reason, the Web server dies or the session times out, the session terminates, and the user is required
to start a new session. Most online transactions are session oriented, with the user initiating a session
performing a set of actions and then terminating a session. Hence, a session bean generally stores its
state in transient variables.
Not all sessions are conversational. Some sessions involve only one interaction between the client and
server. For example, getting a stock quote does not need the multiple invocations of the service the
stock-quote server provides. These sessions are stateless , and their management can be significantly
simplified. To address these different scenarios, the EJB specification specifies two types of session
beans: stateful and session.
In general, the use a session bean is appropriate if the following circumstances hold:
 
At any given time, only one client has access to the bean instance.
 
The state of the bean is not persistent, existing only for a short period (perhaps a few hours).
Once the session bean is chosen, we still need to decide which one to use, stateless or stateful, based
on whether a conversational state needs to be held in the session bean.
Stateless Session Beans
Stateless session beans are components that implement a single-use service. That service can be
invoked many times, but since the component does not maintain any state, the effect is that each
invocation provides a single use. In a lot of ways, stateless session beans provide a reusable single-use
service .
Although a stateless session bean does not maintain a conversational state for a particular client, it may
contain a transient state in the form of its instance variables, as shown in the code example. When a
client invokes the method of a stateless bean, the values of the bean's instance variables represent
such a transient state but only for the duration of the invocation. When the method is finished, the state
is no longer retained. Except during method invocation, all instances of a stateless bean are equivalent,
allowing the EJB container to assign an instance to any client. Most of application servers take
advantage of this feature and pool the stateless session beans to achieve better performance.
Because stateless session beans can support multiple clients and usually are pooled in the EJB
container, they can offer better scalability for applications that require large numbers of clients. Typically,
an application requires fewer stateless session beans than stateful session beans to support the same
number of clients. At times, the EJB container may write a stateful session bean to secondary storage
(called passivation, discussed later). However, stateless session beans are never written to secondary
storage. This further makes stateless beans offer better performance than stateful beans.
The major advantage of stateless session beans over stateful session beans is performance. A
stateless session bean should be chosen if one of following is true:
 
The bean's state has no data for a specific client.
 
In a single-method invocation, the bean performs a generic task for all clients. For example, you
might use a stateless session bean to retrieve stock quotes at any time.
 
The bean fetches from a database a set of read-only data that is often used by clients. Such a
bean, for example, can retrieve the table rows that represent the inventory that currently below
certain level.
In general, the steps for developing EJBs include:
1. Write the remote interface.
2. Write the home interface.
3. Write the EJB implementation class.
4. Compile the EJB and all its supporting files.
5. Write the deployment descriptors.
6. Package and deploy.
Search WWH ::




Custom Search