Sun Microsystems Inc

Chapter 6 Session Bean Component Contract

This chapter specifies the contract between a session bean and its container. It defines the life cycle of the session bean instances.

This chapter defines the developer’s view of session bean state management and the container’s responsibility for managing session bean state.

6.1 Overview

A session bean instance is an instance of the session bean class. It holds the session object’s state.

By definition, a session bean instance is an extension of the client that creates it:

•Its fields contain a conversational state on behalf of the session object’s client. This state describes the conversation represented by a specific client/session object pair.

•It typically reads and updates data in a database on behalf of the client. Within a transaction, some of this data may be cached in the instance.

•Its lifetime is controlled by the client.

Sun Microsystems Inc.

A container may also terminate a session bean instance’s life after a deployer-specified timeout or as a result of the failure of the server on which the bean instance is running. For this reason, a client should be prepared to recreate a new session object if it loses the one it is using.

Typically, a session object’s conversational state is not written to the database. A session bean developer simply stores it in the session bean instance’s fields and assumes its value is retained for the lifetime of the instance.

On the other hand, the session bean must explicitly manage cached database data. A session bean instance must write any cached database updates prior to a transaction completion, and it must refresh its copy of any potentially stale database data at the beginning of the next transaction.

6.2 Goals

The goal of the session bean model is to make developing a session bean as simple as developing the same functionality directly in a client.

The container manages the life cycle of the session bean instances. It notifies the instances when bean action may be necessary, and it provides a full range of services to ensure that the session bean implementation is scalable and can support a large number of clients.

The remainder of this section describes the session bean life cycle in detail and the protocol between the bean and its container.

6.3 A container’s management of its working set

To efficiently manage the size of its working set, a session bean container may need to temporarily transfer the state of an idle stateful session bean instance to some form of secondary storage. The transfer from the working set to secondary storage is called instance passivation. The transfer back is called activation.

A container may only passivate a session bean instance when the instance is not in a transaction.

To help the container manage its state, a session bean is specified at deployment as having one of the following state management modes:

•STATELESS—the session bean instances contain no conversational state between methods; any instance can be used for any client.

•STATEFUL—the session bean instances contain conversational state which must be retained across methods and transactions.