Differences Between Stateless and Stateful Session Beans

Unlike the other EJB types, session beans are divided into two categories. A session bean can either be stateful or stateless . A stateful session bean is said to "maintain conversational state" with its client. Conversational state means that the bean maintains knowledge of actions performed by a specific client across multiple method calls made by that client. The EJB specification states that this is the normal behavior for a session bean. A form of session bean that maintains no conversational state (stateless) is also defined by the specification. The primary tradeoff between the two is efficient use of resources versus client application complexity. Even though stateful is described as being the normal type of session bean, you'll actually find that stateless session beans are more common in typical EJB applications.

With stateless session beans, once a method invocation is completed, the container may use this instance to service a different client. Because stateless session beans don't maintain conversational state, each instance of a particular session bean class is identical to any other as far as the container is concerned . The identity of a session object isn't exposed, so a client of a stateless session bean never knows whether the method calls it makes on a component interface reference are serviced by the same session object each time or not. This and the fact that a client usually does some processing of its own in between calls to a session bean give the container some flexibility. In particular, the container can swap instances back and forth between clients so that it can service many more clients than its number of activated session bean instances. This is an obvious boost to scalability because the number of stateless session beans doesn't have to increase with every increase in the number of clients .

The anonymity of stateless session beans brings up a major difference between the two types of session beans. All instances of a single stateless session bean class are identical, but this isn't true for stateful session beans. After a stateful session bean instance has been activated and associated with a client, it's uniquely identified with that client and it stays with the client until the client is finished with it or the instance is passivated or times out. You'll see how passivation is handled when the session bean life cycle is discussed a little later.

Just as some EJB developers question the relative worth of entity beans, session beans don't come without a small debate of their own. Stateless session beans are accepted without opposition , but some developers believe the nature of stateful session beans makes them a performance bottleneck that should be avoided. It's true that stateful session beans don't scale as well as stateless ones do, but they're being asked to serve a different purpose. First, it's important to recognize that the leading EJB containers are designed to support a large number of concurrent session bean instances executing at one time. If an application serves many concurrent users, it can exceed this number and have to passivate and activate its stateful session bean instances ”but not necessarily any more than it will its entity bean objects. The passivation mechanism is built into the EJB architecture to support scalability, so it doesn't have to be interpreted as a performance barrier . You should keep in mind that there are definite situations where it makes sense to use stateful session beans. If you're implementing workflow functionality that requires the client to perform multiple steps, avoiding stateful session beans forces you to either require more sophisticated clients (capable of maintaining their own state and sending it to the methods of a stateless bean) or store intermediate results somewhere. For approaches that use a database, you might even want to consider an entity bean implementation. You shouldn't use stateful session beans when you don't need to maintain specific client information between method invocations, but you shouldn't avoid them when you do. As long as you recognize the intent of this bean type, you can use it effectively.

Note

A stateless session bean doesn't maintain conversational state with a client, but that doesn't mean that it can't have state. A stateless session bean can have instance variables that hold state just like any other class. The distinction is that a client can't assume that the state held by a stateless session bean is specific to it. If a client sets the value of a stateless bean instance field, there's no guarantee that the field will have that value when the client calls another method. This is because another bean instance might be used to service subsequent calls. You should use instance fields in a stateless session bean only to maintain state that's common to all its clients. For example, a stateless session bean could hold a reference to a data source connection factory that can be used no matter which client calls it.

Identifying the Auction Session Beans

Chapter 5 identified a set of entity beans and dependent objects capable of managing the persistent data for a simple auction site. These entity beans are responsible for business logic specific to the concepts they represent, but a layer of session beans is needed between them and the client to isolate them and implement the workflow business logic. To start with, an AuctionHouse session bean can be used to implement the functionality needed to supply bidders with information about the available auctions and to receive bid submissions and pass them on to the corresponding EnglishAuction entity object. Separating the operations needed to create and maintain auctions into an AuctionManager session bean supports a clear division of responsibility. It also simplifies the management of security roles by isolating end- user bidding functionality from the needs of internal data maintenance users. Both AuctionHouse and AuctionManager represent fairly discrete tasks (for example, generating a list of the open auctions, submitting a bid, creating a new auction, and so on) so stateless session beans can satisfy the requirements for these beans.

As an example of a stateful session bean, a conversational state might be useful when an auction winner is being led through the steps needed to complete the purchase of an item that's been won. You'll often see an online shopping cart concept such as this used as an example of a stateful session bean. This representation can be used for an AuctionCheckout bean to handle the purchasing workflow.

Table 9.1 summarizes the representation chosen for the auction controller classes.

Table 9.1. The Auction Session Beans

Object	Representation
AuctionHouse	Stateless session bean
AuctionManager	Stateless session bean
AuctionCheckout	Stateful session bean

Bean Provider Responsibilities

Many of the responsibilities of a session bean provider are the same as the ones that apply to entity beans. A bean provider that develops a session bean must define its home and component interfaces, implement the bean class, and provide the initial version of its deployment descriptor. This is nothing beyond what's required to develop an entity bean. Session beans don't have primary keys, so you don't have to be concerned about declaring a primary key class. You also don't have to consider BMP versus CMP type issues. The most significant choice you make right away for a session bean is whether to design it as stateful or stateless. Along with this goes the question of whether the bean will support local or remote clients (or both). You'll also see later in Chapter 12, "Transactions," that you must choose between two methods of managing transactions when you implement a session bean. This chapter will stick with the assumption that the container is managing the transactions, which is the more common approach.

For more information on implementing transactional bean methods, see "Using Container-Managed Transactions," p. 344 .

By the end of this chapter, you'll be able to declare the interfaces for a session bean, implement the bean class, and specify its deployment information.