Women in Technology

Hear us Roar



Article:
  Stateful Session EJBs: Beasts of Burden
Subject:   What about clustering
Date:   2001-10-04 00:14:25
From:   ampieb
In a database based web clustering architecture, like WebSphere's, one would store session info in a central session bean rather than in an HttpSession. The web clustering would then require much less database overheads, since only the handle to the session bean needs to be stored centrally, not the entire session bean. It really depends on what you want from your architecture, and where you want the bottlenecks to be. As with any technology, you just have to know where to use it. Technology is not conniving and misleading, developers make stupid decisions.
Main Topics Oldest First

Showing messages 1 through 1 of 1.

  • What about clustering
    2001-10-08 06:01:10  kestrel [View]

    > Technology is not conniving and misleading,
    > developers make stupid decisions.

    I agree with you on both points: technology is not misleading, and in my experience as a middleware developer I have made many stupid decisions. However, I think Tyler's point about the EJB Specification being misleading with respect to the applicability of Stateful Session Beans is a valid one.

    There is no reference implementation of the EJB specification; if a developer wants to explore a particular issue, he has two options:


    • Try it out on whatever app server is available. There are, of course, few guarantees that the functionality of a particular app server will be duplicated on any other J2EE-compliant server.
    • Read the EJB Specification to determine the minimum guarantees made to developers for that particular aspect.


    The authors of the EJB 1.1 and 2.0 specifications have made an exceptional effort in making the material accessible to all developers, partially through the use of examples such as the "Shopping Cart" example in question. This particular example, however, can be misleading if your concept of the functionality of a shopping cart includes persistent failover.