Dive into connection pooling with J2EE

Manage access to shared, server-side resources for high performance

1 2 Page 2
Page 2 of 2

What is wrong with the above picture? First, the stateful session object (NewCustomerBean) opens up the connection object in the setEntityContext and holds on to it until the end of the use case -- a rather costly implementation if the number of users (sessions) increases rapidly. Second, and more important, since connection objects are not serializable, per the EJB 1.2 specification, the container can discard the bean instance upon passivation (i.e., move the session bean from its active state to a bean instance pool).

One alternative is that resource connections are acquired and released in the ejbActivate() and ejbPassivate() methods of the session bean, respectively. Without connection pooling, that is of course expensive and not recommended. With pooling however, connections can be acquired and released with minimum overhead for the EJB layer, using that technique. The point here is that beyond the facilities offered by the specifications and the implementations, design choices are, as always, key performance determinants.

A second consideration is around the issue of authentication. You might have observed that pooled connections imply shared connections, which then imply that the connections are not tied to a specific authentication credential. For example, in the case of JDBC 2.0 connections, an application server pool manager requests, at startup, a preset number of connections from the DB manager, using a single authentication credential (typically a userid/password) stored in a configuration file. Sometimes that may not satisfy the security policy for the application. The same argument applies for LDAP connections that require binding with a specific credential to a LDAP subtree. In those situations, one alternative might be to use a cached connection that has been established using a specific credential, which can be reused for the same type of credentials. The downside to that is that cached connections are held for long periods of time. Another alternative might be to use generic connections for resources and implement certain application-level security.

Conclusion

In this article, I showed the need for connection pooling resources in a J2EE environment, based on the shared nature of the resources as well as the EJB components that access them. You saw the facilities defined by the JDBC 2.0, JMS 1.02, and the JNDI 1.2 Standard Extension APIs as well as vendor support for the implementation of those API interfaces. Although the vendor-specific solutions are robust, you use them at the cost of EJB portability. The upcoming J2EE Connector Architecture 1.0 addresses that issue and makes resources pluggable, relieving the EJB layer from dealing with vendor-specific libraries. And finally, I explained why your design plays an important role in taking advantage of those pooling techniques for delivering high-performance J2EE applications.

Siva Visveswaran has been working with Java for more than three years and has been smitten by J2EE. Most recently, he has been involved in architecture and development of large and complex J2EE applications for Fortune 100 financial service companies and dot-coms. He has more than 12 years experience in the IT industry and is currently working as a principal consultant at a large management consulting firm, specializing in e-business architecture, infrastructure technologies, and content management solutions. Siva has a master's degree in computer science from Wayne State University in Detroit, Mich.

Learn more about this topic

1 2 Page 2
Page 2 of 2