Addendum - Enterprise Java Computing : Applications and Architecture

Page 332 - 333 : To the Note on pages 332 and 333, I would like to add the following. The entire note with the additions should read as follows:

Note

Notice I have not talked about database connection pooling in the previous paragraph. While the current EJB specification does talk about instance pooling, it has nothing to say about connection pooling.

To see how these instance management algorithms work, think about the EJB component instance as living inside the EJB container. When a method request travels from the client outside the container to the component instance, it must travel through the container. The container intercepts the method before it is delivered to the enterprise bean. This gives the container an opportunity to participate in the delivery of that request. And one of the ways the container can participate is by injecting an instance management algorithm into that delivery.

Instance management is about faking out the client. The client code thinks it has a dedicated middle-tier instance, just waiting for the next client request. But the client has no idea whether an actual middle-tier instance really exists. All the client knows is this: By the time the method is actually delivered by the container, something needs to be there to receive that method.

Instance Pooling and EJB

EJB uses an instance management algorithm called Instance Pooling (IP). In the IP algorithm, the middle-tier instances are themselves pooled, not the database connections. After the method has been intercepted by the container, and before it has been delivered to the enterprise bean instance, the container does not create a brand new instance to process the request—it uses one from a pool of instances. When the instance has finished processing the method, the container does not destroy it. Instead, it is returned to the pool.

Because the IP algorithm does not constantly create and destroy instances, it needn’t worry about the efficiency of creating and destroying database connections. Certainly, the actual creation of the instance may sometimes be slow, but that happens infrequently.

The IP code moves the creation and destruction of the database connection out of the business logic and into the methods executed when the instance is first created during ejbActivate() and finally destroyed during ejbPassivate().

In EJB, the actual middle-tier EJB component instance may be pooled. Since the component may not be running all the time, it does not use up a lot of system resources.

As soon as the call comes in from the client, the EJB container may use an EJB component instance from a pool of shared instances. And as soon as the request is serviced and the reply is sent back to the client, the actual EJB component is returned back to the pool. It may not be destroyed.

Generally, this is what happens on the Server when a client requests services from a typical stateless EJB component:

Read the component's state from the database.
Perform the business logic.
Write the component's changed state, if any, back to the database.

EJB isn't stateless between calls from the client. For stateful beans the above scenario is true if and only if a call to the component coincides one to one with transaction boundaries. You can easily have the following scenario:

Read the component's state from the database.
Perform the business logic.
Return data to the client.
Client makes 0-N more calls to the bean, performing business logic, and database operations.
Write the component's changed state, if any, back to the database.

IP is conceptually simple and has less algorithm dependent code in the business logic. In fact, even the read and write of the component state can be moved out of the business logic if this algorithm is coupled with transactional notification.

This is where the JDBC 2.0 specification could help because within it you'll find built-in support for database connection pooling. This means any EJB product can use JDBC 2.0 for relational database access and the connection pooling can be portable across EJB container products.