0

Regarding the use of session EJBs, what I have seen until now in "real world applications" (if I remeber correctly) are stateless session EJB used as "facades" for transactional (via CMT) business logic methods. I have not seen any stateful session EJBs, though. Indeed it seems that their use as "shopping carts" for example, found in Java EE books, means that their state should be stored in some way in the persistent storage. But this seems to suggest that also other parts of the application domain, as modeled in the database, should be mapped to stateful EJB-s, which seems to be overly complex.

So, could you give specific examples, based on your experience/expertise, of how stateful session EJBs used in today's (as opposed to 2003, for example) applications?

BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
John Donn
  • 1,718
  • 2
  • 19
  • 45

2 Answers2

2

Stateful EJB can persist their state in the database but Stateful EJB do not necessarily need to persist their state in a database. A Stateful EJB is obliged to store and remember in memory the conversational state with the client only for the duration of the "conversation".

Below you may find some real world examples identified in some cases that are suitable for Stateful EJB usage according to the Java EE 7 Tutorial: Stateful session beans are appropriate if any of the following conditions are true.

  • The bean's state represents the interaction between the bean and a specific client. Real World Example: Stateful EJB implementation of an online transaction with login, action, logout.

  • The bean needs to hold information about the client across method invocations. Real World Example: Stateful EJB could be used to implement a shopping card. Data can be persisted or not, for example for an eshop that does not require a login, the shopping card could be discarded if the user does not finally checkout the items he has collected.

  • The bean mediates between the client and the other components of the application, presenting a simplified view to the client. Stateful EJB could be used to implement a persistence abstraction.

  • Behind the scenes, the bean manages the work flow of several enterprise beans. Real wold example: Stateful EJB could be used to implement an online vacation booking transaction where the EJB models an agent that books a plane ticket, a car and a hotel from different providers using other EJBs and then returns the results to the client.

The above examples demonstrate the applicability of the concept in some examples. Actually using Stateful EJBs in a real environment nowadays would result in a purer design however it would not be optimal if performance and complexity are taken into consideration. See also Stateful EJBs in web application?.

Community
  • 1
  • 1
Spyros K
  • 2,480
  • 1
  • 20
  • 37
  • 2
    I tried to demonstrate the applicability of the Stateful EJBs in a set of Stateful EJBs suited cases. I used to the EE tutorial as a reference for suited cases and provided simplified examples based on personal experience. Your clarification shows that you are interested more into knowing if the concept is actually beneficial in real practice. I would say that indeed Stateful EJBs tend to be avoided and Stateless EJBs are preferred for better performance and simplicity. Others think this way. http://stackoverflow.com/questions/2811312/stateful-ejbs-in-web-application?rq=1 – Spyros K Aug 05 '16 at 09:45
1

We currently have a couple of Stateful EJBs in one of our applications running on production. So I suppose, it can be considered as a real world example.

This EJBs are used to provide large amounts of data to the clients by dividing this data in chunks and sending this chunks on demand. All this works as follows:

  • client prepares a request, specifying filters he wants data to be looked up against;
  • he submits this request using Stateful EJB method;
  • request is processed on a server and result set is prepared;
  • as a response to his request client gets a descriptor to the server-side result set;
  • having this descriptor he now can fetch chunks of data using Stateful bean methods.

Was a Stateful bean a necessity in solving such a problem? Not at all.

Described functionality could be achieved with a Stateless bean. But in this case we have only two ways of implementing it. Either we are forced to prepare result sets for requests each time a client needs next chunk of data (as we don't have any state), or we use some static storage and take care of security and concurrent access by our own. /By security here I mean preventing situations in which one client can gain access to the result set of another using his descriptor/

The first way is simply slower and less efficient comparing to implementation on Stateful beans. The second way is more complicated and less stable under load due to synchronization.

With Stateful bean we just get what we need in an efficient manner and without extra effort.

Aleksandr Erokhin
  • 1,904
  • 3
  • 17
  • 32