Previous    Next

Session Beans in the Sample app

The sample app requires us to hold server-side state on behalf of users executing some use cases. Ticket reservations must be held during the tutorialing process; user profiles may be held during the tutorialing process. However, pages outside the tutorialing process do not require session state to be maintained. We could hold this session state in SFSBs. However, there are good reasons to prefer web container state management:

• Using SFSBs would tie us to using EJB. There's no other reason to predicate our architecture on using EJB; we've merely chosen to use EJB where it simplifies transaction management.

• This is a web app. There's no need to hold session state on behalf of remote RMI clients.
• Web container state management is likely to outperform SFSB state management. We won't need to invoke EJBs to access user state, and there may be a reduced overhead of state replication in a cluster.
• Holding state in the web container is simpler. We'll probably need to use HttpSession objects regardless of whether we use SFSBs. The added complexity of JNDI lookups for SFSBs would produce no benefit.

Thus we'll hold user state for the ticketing app in the web container, using HttpSession objects, and use SLSBs. As the amount of session state involved is modest (once we ensure that reference data is shared between users) and we are invoking our single EJB through a local interface, there is no problem passing user state to the EJB container with each method invocation.

We'll be using CMT, as the major reason we have chosen to use an EJB to implement the tutorialing process is to simplify transaction management.

Previous    Next