Lesson 6 | Stateful and Stateless Session Beans |
Objective | Describe the difference between stateful and stateless session beans. |
Stateful and Stateless Session Beans
In Java EE (Enterprise Edition), session beans are components used to implement business logic in enterprise applications.
They can be classified into two categories:
stateful and
stateless session beans. The key difference between them lies in how they manage state.
- Stateless Session Beans:
"Stateless session beans" do not maintain any client-specific state between method invocations. Each time a client invokes a method on a stateless session bean, it may get a different instance of the bean from a pool, as no client-specific data is stored in the bean itself. These beans are typically used for operations that are independent of previous method calls, such as performing calculations, sending notifications, or processing data.
Characteristics:
- No Client State: Stateless session beans do not store any state related to a specific client between method invocations.
- Pooled Instances: The container can pool instances of stateless beans and reuse them across multiple clients. This improves scalability, as fewer bean instances are needed.
- Short Lifespan: The lifecycle of a stateless session bean is short-lived, often tied to individual method calls.
- Use Case: Commonly used for tasks like transaction processing, calculations, or any other service that does not depend on previous interactions with the client.
Example Use Case:
A stateless session bean might be used to validate a credit card number or perform a stateless operation like tax calculation, where the same logic can be applied to different clients without tracking individual client data.
- Stateful Session Beans: "Stateful session beans" maintain state between method invocations, meaning that they retain data for a specific client across multiple requests. This state is typically stored in instance variables, and it is unique to each client. Stateful beans are useful when the interactions with the client require maintaining conversational state, such as managing a shopping cart in an e-commerce application.
Characteristics:
- Client-Specific State: Stateful session beans maintain the state of a specific client session across multiple method calls. The state is typically stored in instance variables.
- Dedicated to One Client: A stateful session bean is dedicated to a single client for the duration of the conversation, which means that it cannot be shared among clients.
- Longer Lifespan: These beans live longer than stateless session beans, often lasting for the duration of the client session.
- Passivation: When not actively in use, the container can "passivate" (serialize) a stateful session bean to free up resources, then "activate" it again when needed.
- Use Case: Used for operations that require maintaining a conversational state with the client, such as a sequence of operations in a multi-step workflow (e.g., online shopping, banking transactions).
Example Use Case: A stateful session bean might be used in a shopping cart application where the items added to the cart by a client need to be retained across multiple interactions with the server.
Comparison Summary:
Feature |
Stateless Session Bean |
Stateful Session Bean |
Client-Specific State |
Does not maintain client-specific state |
Maintains client-specific state |
Instance Reuse |
Instances are pooled and shared |
Each client gets a dedicated instance |
Lifespan |
Short-lived (per method invocation) |
Long-lived (per client session) |
Scalability |
More scalable due to instance pooling |
Less scalable due to dedicated instances |
Use Case |
Independent operations (e.g., services, calculations) |
Conversational operations (e.g., shopping cart, banking) |
Conclusion:
The choice between stateful and stateless session beans depends on the nature of the business logic. **Stateless session beans** are more efficient and scalable for independent operations, while **stateful session beans** are useful when you need to maintain a client's state across multiple interactions.
Stateful Session Beans
Normally, session beans are stateful, with the container making sure the bean object never loses its state. When a client requests the container to create a session bean instance on its behalf, it usually passes the instance the appropriate information that the session bean uses to set its initial state. The client assumes that the bean object, once created, will always be available with the state maintained. Even if the container needs to temporarily store the bean instance on secondary storage, it must makes sure it state is restored when it is read back in.
Stateful session bean example: the shopping cart
An example of a session bean is a shopping cart. The shopping cart instance has a one-to-one relationship with the shopper who is the client;
it can be discarded when the client completes the purchase of the shopping cart contents and it is emptied. Its state is the current contents. If the client has forgotten his wallet, then the store can move the shopping cart off to one side while the shopper drives home to get it.
When he returns to the store, the shopping cart can be retrieved and the purchase completed. If the store catches fire (equivalent to the container crashing) while shopping, the shopper can abandon the cart and will return to shop when the store is back in operation.
The state of a stateful session bean instance lasts until the bean instance is removed.
If the bean instance's state needs to be saved for later use by another bean, it must be stored in some persistent store before removal. The new session bean instance will have to initialize itself from the persistent store when it is created.
Stateless Session Beans
Stateless session beans
[1], as their name suggests, have no state held on behalf of the client and only need to exist for the duration of a single method call. The container can pool multiple bean instances and grab the most convenient one when a client needs it. The container can manage stateless session beans very efficiently.
- Stateless session bean example: the currency converter:
An example of a stateless bean is a currency converter. Give it a value in a certain currency and it will convert it to the equivalent value in US dollars. It does not maintain a state, for the client, across method calls. However, it does have a private state, the conversion rates; however, that state is general to all clients.
In the next lesson, entity beans will be introduced.
[1]Stateless: The property of an object such that it contains no information that needs to be preserved across method calls.