- Stateless Session Beans are business objects that do not have state associated with them.
- The @Stateless annotation is used to mark the class as Stateless Session Bean.
- Access to a single bean instance is still limited to only one client at a time and concurrent access to the bean is prohibited.
- In case concurrent access to a single bean is attempted anyway the container simply routes each request to a different instance. This makes a stateless session bean automatically thread-safe.
- Instance variables can be used but the contents of those instance variables are not guaranteed to be preserved across different client method calls.
- Instances of Stateless Session beans are typically pooled because all stateless bean instances are equivalent when they are not involved in servicing a client-invoked method.
- The container can choose to delegate a client-invoked method to any available instance.
- Eg. If a second client accesses a specific bean right after a method call on it made by a first client has finished, it might get the same instance or the container may delegate the requests from the same client within the same transaction to different instances.
- The lack of overhead to maintain a conversation with the calling client makes them less resource-intensive than stateful beans.
- Because there is no need to maintain the state across method calls, a stateless session bean is never passivated.
- A stateless session bean can implement a web service, but a stateful session bean cannot.
Examples
- Sending an e-mail to customer
- Adding an item to the database
- Getting a particular list of items from the database
- Any operation which can be completed in one single shot.
