Java Computing - Applications and Architecture
By Govind Seshadri
Contributing Author: Gopalan Suresh Raj
(Chapters 7, 8 and half of 6)
Cambridge University Press (SIGS Books) - Managing Object Technology Series, No 22 (June 1999, Paperback, 360 pages) ISBN: 0521657121.
Chapter 8: Enterprise JavaBeans
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
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 requestit 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 neednt 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:
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:
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.
This site was developed and is maintained by Gopalan Suresh Raj
This page has been visited times since August 10,1999.
Last Updated : Aug 10, '99
All products and companies mentioned at this site are trademarks of their respective owners.