The Internet and Java have provided programmers with a double-edged sword. The two technologies offer a framework for building groundbreaking solutions, but their lack of maturity often has programmers writing functionality typically provided by older tools. Shared resource management is a good example. Fortunately, IBMs WebSphere Application Server for AS/400 goes a long way toward providing services that programmers have come to expect from a good runtime environment. In the case of shared database resources, for example, WebSphere Application Server offers the IBM Connection Manager.
Database Interaction and Servlets
To connect to and interact with databases, Java programmers typically use the Java Database Connectivity (JDBC) API. The process is straightforward: You create a connection to the database through the Connection class, specify an SQL query string by using a Statement object, and scroll through the results of the SQL query via the ResultSet object returned by the Statement object. Connecting to the database can be expensive (usually several seconds), so most Java programs create a database connection once and reuse the connection throughout execution of the program.
Unfortunately, this is not a viable approach for servlet programmers. A servlet executes as a single process running a thread for each request, and each request requires its own database connection. Servlet performance would be poor if each request created its own connection, but because requests share resources such as instance variables, servlet programmers do not have the option of creating just one connection. If they did have that option, access to the connection would have to be synchronized, meaning that the servlet could handle only one request at a time.
To solve this problem, servlet programmers create a class that manages a pool of database connections. An instance of that class is initialized in the init() method of the servlet. When a request needs to access the database, the object typically returns a pooled connection, saving the request from the performance hit of a database connection. Connection Manager provides such an object. It also provides an administrative tool that monitors database connection statistics and has settings for tuning servlet performance to your specific connection needs.
The Connection Pool Model
Figure 1 shows the basic connection pool model. Rather than create its own database connection, the servlet requests a connection from a Connection Manager object, passing along a specification that describes the type of connection it needs. The specification details items such as the connection pool name and database name. Connection Manager then searches the pool for an existing but unused connection that matches the specification. If it finds one, that connection is returned.
Otherwise, Connection Manager creates a new connection, adds it to the pool, and returns it to the servlet.
Connection pools are configured in WebSphere to maintain a minimum number of connections. This minimum number creates a pool of connections when WebSphere starts up. Connection pools are also configured with a maximum number of connections so WebSphere starts another connection if all connections in the pool are busy but the number of connections has not yet reached that maximum. However, if a servlet requests a connection and the pool has already reached its maximum number of connections and all connections are in use, the servlet, depending on the connection pool configuration, waits until either a connection frees up or Connection Manager returns an error.
Pools are typically organized by connection properties such as database vendor and timeout value. WebSphere comes preconfigured with pools organized by database vendor for DB2, Oracle, Informix, SQL Server, and Sybase.
Setting Up a Connection Pool
Connection pools are configurable through the WebSphere Application Server administrator panel under section Setup and subsection Connection Management. You can access your AS/400s WebSphere configuration panel from your Web browser by specifying your domain name or IP followed by port ID 9090 (http://199.140.33.5:9090). To configure WebSphere from the Internet, you must start the administration server via the Start TCP/IP Server (STRTCPSVR) command:
(STRTCPSVR SERVER(*HTTP) HTTPSVR(*ADMIN))
To ensure that WebSphere has been started, you also need to have an HTTP server instance started that uses WebSphere features. Figure 2 shows the WebSphere configuration screen.
When you click Connection Mgmt, a tabbed dialog appears on the right side of the screen. The connection pools are listed under this pool list tab. In creating a pool, you must specify the following settings (see Figure 3):
The Pool Name setting is used by servlets to identify the connection pool.
The Maximum Connections setting is the maximum number of connections maintained by the pool and is set at the maximum number of simultaneous active user requests that you expect will hit your database on any given day.
The Minimum Connections setting is the minimum number of connections contained in the pool and is based on the minimum number of active user requests that you expect.
The Connection Time Out setting specifies how long Connection Manager waits for a connection to become free when all connections in the pool are in use and the number of connections has reached the maximum. (A setting from 1,000 to 2,000 milliseconds is recommended.)
The Maximum Age setting specifies the number of seconds for which an assigned connection can be idle before the reap process releases the connection from the servlet that acquired it.
The Maximum Idle Time setting specifies the amount of time an unassigned connection remains in the pool before being marked for reclamation by the reap process.
The Reap Time setting specifies how often (in seconds) the reap process runs. Then, theres the reap process itself. Periodically, Connection Manager executes a reap process, which removes orphaned or idle connections. The Minimum Connections setting prevents Connection Manager from removing too many, and you always want some number around for the next set of servlet requests.
Using a Connection Pool
Connecting to a database through a connection pool requires initializing a Connection Manager object, creating a connection specification, and requesting a connection from the Connection Manager object. After your servlet obtains a connection from the pool, you can use the connection just as you would any JDBC connection. However, it is important to release the connection after you are finished with it. Otherwise, the connection is used only once and hangs around until it times out and is reclaimed by the reap process. This connection hoarding eliminates the benefits of having a pool of connections and kills performance because valuable system resources are not released.
To use connection pools, your servlet needs the following instance variables:
protected IBMConnMgr connectionManager;
protected IBMJdbcConnSpec connectionSpec;
protected IBMJdbcConn connection;
IBM provides classes IBMJdbcConnMgr, IBMJdbcConnSpec, and IBMJdbcConn as part of WebSphere. You use an instance of IBMJdbcConnMgr to request connections. (To create an instance of this class, use a static method of the IBMConnMgrUtil class.) An instance of IBMJdbcConnSpec defines your connection specification; pass this connection to Connection Manager every time you request a connection to a database. The connection returned is an object of IBMJdbcConn and contains the underlying JDBC connection. The object also provides a method that releases the connection back into the connection pool. These classes are all in package com.ibm.servlet. connmgr.
Your init() method should contain code that gets the Connection Manager object and code that creates the connection specification object:
connectionManager = IBMConnMgrUtil.getIBMConnMgr();
connectionSpec = new IBMJdbcConnSpec(poolName, aBoolean,
jdbcDriverName,
jdbcConnectionURL,
userName, password);
The static getIBMConnMgr method creates the Connection Manager object for you. To create an instance of IBMJdbcConnSpec, use the standard constructor. The Boolean passed in specifies whether or not the servlet waits for connections. Normally, you pass in true; all other parameters are character strings.
In the service() (or doGet() or doPost(), depending on your servlet design) method, you use the IBM connection manager and connection specifi-cation objects to get an instance of IBMJdbcConn. You then use that object to get your JDBC connection:
connection =
(IBMJdbcConn)connectionMgr.getIBMConnection(connectionSpec);
java.sql.Connection conn = connection.getJdbcConnection();
java.sql.Statement stmt = conn.createStatement();
java.sql.ResultSet rs = stmt.executeQuery(Select...);
... process data from result set ...
connection.releaseIBMConnection();
When you are done, you must release the connection by using the release IBMConnection() method.
Party Line
Bit by bit, IBM and others are providing the tools and support serious developers require for business-critical applications. For more information on Connection Manager, read Chapter 7 of IBM WebSphere and VisualAge for Java Database Integration with DB2, Oracle, and SQL Server. You can access this Redbook online at www.redbooks.ibm.com. Read the book. Go through a few tutorials. Add yourself to the growing ranks of master servlet developers.
Related Material
IBM WebSphere and VisualAge for Java Database Integration with DB2, Oracle, and SQL Server, Redbook (SG24-5471-00)
DB2/400
Oracle
JdbcDb2 pool
Connection JdbcOracle pool Connection
Figure 1: Here's the relationship between components when they use connection pools.
Connection
Request
JDBC Connection
Connection
Connection Connection
Connection Manager
Connection Connection
Connection
Servlet
LATEST COMMENTS
MC Press Online