Tuning JDBC Connection Pools in WebLogic Server


If your application uses database connections, you can improve performance of your application by using the WebLogic JDBC connection pools. Opening and closing a database connection are expensive operations and can be optimized by using connection pools. If you have configured a connection pool in WebLogic Server, the server will create database connections while starting. These connections will be stored in the pool and will be available to any server subsystems and clients. The client can fetch a connection from the pool, use it to perform some database activity, and then close it. When the client closes the connection that it has obtained from the pool, that connection is returned to the pool and is available to other clients . Thus, using connection pools, you can eliminate the overhead of creating and closing database connections each time.

The connection pools can be configured to define the initial number of connections, maximum number of connections, and the way the pool should grow and shrink. All these parameters need to be set appropriately to achieve optimum performance for your application.

The InitialCapacity attribute defines the number of connections the server will create while starting or when the connection pool is targeted to a server instance. The server opens the number of database connections defined in InitialCapacity and stores them in the pool.

During the development phase, when you want the server startup to be quick, you should set the attribute to a low value.

In a production phase, the value of InitialCapacity should be equal to the value of MaximumCapacity . As a result, the maximum number of database connections required by your application, depending on the maximum concurrent load, will be created by the server during startup time.

This will slow down the startup but will prevent the server resources from being wasted for creating additional connections after the server has started.

The MaxCapacity attribute defines the maximum number of database connections a connection pool can contain.

In production environments, you should set the MaxCapacity parameter depending on the number of concurrent client sessions that require database connections and the number of connections required by each request. This prevents any client session from waiting for some other client session to release a connection back to the pool. This parameter is independent of the number of execute threads in the server.

WebLogic Server also provides other parameters that can be configured for a connection pool, which would optimize resources in the server. It is a good practice to set the ShrinkingEnabled attribute for the connection pool to true . When this attribute is set, the pool will shrink back to its InitialCapacity size when the server detects that connections created during increased traffic are not being used. This frees WebLogic Server as well as database resources when the period of peak traffic ends. When you set this parameter, the size of the connection pool will fluctuate between InitialCapacity and MaxCapacity .

The RefreshMinutes attribute of the connection pool defines the period during which database connection tests will be carried out. During the test, each unused connection is tested using the test table configured. Connections that fail the test are closed and reopened to re-establish a valid database connection. Do not set the RefreshMinutes parameter to a very low value because doing so would increase the frequency of the tests and cause unnecessary overhead on the server.

It is also a good practice to close the JDBC connections immediately after you are done with the database operation in your application code. Database connections that are not closed could lead to unnecessary memory leaks and cause database resource starvation .

Caching Prepared SQL Statements

You can configure a prepared statement cache for each connection pool in WebLogic Server. The size of the cache can be set using the Administration Console. The prepared statements are stored in the cache until the size reaches the maximum limit. If an application calls any of the prepared statements stored in the cache, WebLogic Server reuses it. This eliminates the need for parsing the prepared statement in the database each time, as well as improves the current statement s performance.



BEA WebLogic Platform 7
BEA WebLogic Platform 7
ISBN: 0789727129
EAN: 2147483647
Year: 2003
Pages: 360

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net