Discussions

EJB design: stateful session beans

  1. stateful session beans (5 messages)

    I am trying to use a stateful session bean across different servlets and find that I am apparently creating a new bean from each servlet. How do I get stateful session beans to know about one another (or better yet do I need to create a new bean each time).

    Threaded Messages (5)

  2. stateful session beans[ Go to top ]

    well, I'd say this depend on your requirement. Stateful session beans are supposed to remember the state of a client over the session. So if the same client is calling all those servlets and they in turn are making call to the EJB, then I think you should take the approach of having a factory which provides a reference to the stateful session bean. This way all the servlets would be accessing the same stub and hence the same instance.

    If you don't mind, then could you specify your exact requirements?

    Thanks
    Ansuman
  3. stateful session beans[ Go to top ]

    I have 4 pages which I need to traverse back and forth through and maintain information which pertains to all 4. I have been doing this in a container class on the webserver successfully but would like to make use of stateful session beans. We are using ejb's and I am able to instantiate a stateful bean from my servlet, but the second time I go to access that bean (create a home and remote interface) it creates a new bean that doesnt know anything about the prior bean. I am not sure how to grab the prior bean from a different servlet. While we are using JSP pages and this is suppose to be very easy via tags, the current framework is set up to obtain page info from postdatagets in the servlets. Any advice would be appreciated.

    Ken
  4. stateful session beans[ Go to top ]

    I think you miss the whole idea behind Session EJBs.

    Session EJBs are acquired with a "ejb=home.create(...)", put to use like "ejb.task1(); ejb.task2();" and released with a "ejb.remove()".

    If your Session EJB is a stateless session EJB, the container does not honor create() and remove(). That is, the container is free to supply you with any instance of the EJB on method invocation, so, task2() may be executed by any EJB, not necessarily the one that executed task1(), for stateless session EJBs.

    If you Session EJB is a stateful (conversational) one, the container honors create() and remove(), so, you can talk to the same EJB instance *as long as you use the same reference*.

    Using create() in each servlet, you are not accessing the stateful session EJB you acquired previously but acquiring a reference to a new one. Once you create an EJB for a user, you should save the reference to it for accessing it for further requests from the same user.

    Storing the reference in the HTTP session is easy. Whenever the servlet gets a request, get the attribute that holds the reference to the stateful session EJB.

    ejb = (EJB's remote) request.getSession().getAttribute("ejb"); // get saved ref

    If the attribute's not there, a stateful session EJB was not acquired for the session before: get the home object, get the reference and put the reference into the attribute.

    if (ejb == null) { // no saved ref
      obj = getHome().create();
      ejb = (EJB's remote) PortableXXX.narrow(obj,...);
      request.getSession().setAttribute("ejb",ejb ); // save ref for later
    }
  5. stateful session beans[ Go to top ]

    To augment the reply above about storing the session bean reference in the http session, if you store the EJB Reference i.e. EJBObject in the http session then you may have an issue if the container "times out" the bean.

    Perhaps an alternative would be to store the EJBHandle to the stateful session bean in the http session. That way, if the bean passivates, there is no problem. Perhaps this is more scalable. Of course, I'm assuming here that your beans time out more rapidly than your http sessions. Other than that since both EJBObject and EJBHandle are ultimately serializable I agree on the original reply's recommendation.

    Thoughts on using the handle instead of the reference, anyone?
  6. stateful session beans[ Go to top ]

    the lifetime of a statefull session bean has nothing to do with the session object in your web application. That is a bit confusing.

    The state of a statefull session bean starts when you create the ejb (home.create), and persists until you remove the ejb.

    This means with one web client you could have many statefull session beans for different simultaneuos use-cases controlled by that one web client. Every "create" of a statefull session bean means: start a "new client environment where i can store state".

    You have no choice (do you?) but storing the reference of your statefull ejb in the web session object, because you need that same reference for handling the next page.