aspose file tools*
The moose likes EJB Certification (SCBCD/OCPJBCD) and the fly likes EJB Stateles and statefull from servlet point of view Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » EJB Certification (SCBCD/OCPJBCD)
Bookmark "EJB Stateles and statefull from servlet point of view" Watch "EJB Stateles and statefull from servlet point of view" New topic
Author

EJB Stateles and statefull from servlet point of view

Kiril Nugmanov
Ranch Hand

Joined: Jul 09, 2008
Posts: 42
Hi all,

I'm wondering about usage of Statefull EJB in servlet/JSP. As I understand servlets aren't thread safe (only HTTPSession, httpServletRequest and local variables are) so:
  • using DI for servlet is worthless
  • access statefull via stateless won't work

  • But while serachig the example of usage statefull EJB I've found following sollution: put obtained statefull EJB into HTTPSession and afret that use saved object. But the same I can do with stateless. While I'll be holding object in session there is no any advantage of Statefull against stateless. Am I right?

    SCJP5, SCWCD5, SCBCD5, OCPJWSD5, OCMJEA 5
    Davide Crudo
    Ranch Hand

    Joined: Sep 08, 2009
    Posts: 62
    ...The rule is that whenever possible, forget about Stateful beans (for obvious reasons, like allocating precious resources to just one client instead of sharing them...)

    but there are cases you will need them, like:

    1) You want to maintain the transaction open during subsequent calls. Regarding this i was reading a while back, an example of an airline booking. If you plan to book 3 flights, and you want those flights to either be booked all together, otherwise the transaction should fail, then you need a Stateful bean, so you can rollback the transaction in case of problems (you can keep the transaction open between method calls using an extended persistent context)

    2) As you mentioned, to keep state between calls, i.e. a shopping cart

    3) You need a Stateful session bean if you want to implement the SessionSynchronization interface. The reason you may want to implement it is in the case as you mentioned when you have a Servlet. If you access the HTTPsession to set your own variables, you might need to use SessionSynchronization to keep those calls consistent. You can read how it works here.

    Dave


    SCJP, SCBCD
    Mihai Radulescu
    Ranch Hand

    Joined: Sep 18, 2003
    Posts: 918

    Hi guys,

    From my point of view the servlet and the stateful beans colide because of the stateless nature of the servlet. There is only one servlet instance and severals requests this brings at least two major problems :
  • if the the logic is spread over request can be that one request may close the bean (by calling one of its remove methods) and the other requests still want to work with the bean which goes invalid
  • if more users interact with one servlet and the statefull bean is used to store user specific information the all the user will share the same information, which in some situations (like shopping list) may be unpleasant.


  • Kiril, why do you think that using DI for servlet is worthless ? This is the only way to obtain resources. Without DI you don't have any other possibility to get a bean instance.

    Regards
    Mihai


    SCJP, SCJD, SCWCD, OCPJBCD
    Davide Crudo
    Ranch Hand

    Joined: Sep 08, 2009
    Posts: 62
    @Mihai

    I understand your concern, but you can find the Sun Duke's Bookstore application example
    where they show how to build a servlet to handle multiple clients using the HttpSession object,
    you can find the specific page here and the Start of the project here.

    Dave
    Kiril Nugmanov
    Ranch Hand

    Joined: Jul 09, 2008
    Posts: 42
    Hi all,

    @Mihai Radulescu: as You mentioned servlets by nature are stateless and if I would try to use DI for statefull EJB - I will allways get new("empty") EJB. Thus
    Davide Crudo wrote:
    ...The rule is that whenever possible, forget about Stateful beans (for obvious reasons, like allocating precious resources to just one client instead of sharing them...)

    Mihai Radulescu
    Ranch Hand

    Joined: Sep 18, 2003
    Posts: 918

    @ Kiril : when you call a business method on a stateless bean then : if the beans is not associated with the session a new one is created and if not then the actual bean is used (to mentain the conversation). The problem is that every time when you do a JNDI look up for a stateful bean a new session is created. So if you keep doing JNDI lookups you will continuous get new sessions and new stateful beans. The solution with the HttpSession is preferable because the session is specif to the user, otherwise you need some problematically way to keep together the user and its specific changes.
    So, to conclude the reason for "new empty stateful beans" is not the servlet's stateless nature, it is the JNDI look up mechanism for stateful beans.

    Regards
    Mihai
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: EJB Stateles and statefull from servlet point of view