Stateless Session Bean Introduction

  • 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.


  • 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.

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.