Basic Principles of Database Connection Pool

Basic Principles of Database Connection Pool

Basic Principles of Database Connection Pool
In the traditional database connection mode (that is, using drivermanager to connect to the datasource), a database connection object corresponds to a physical database connection, database Connection establishment and closure are system-consuming operations. In a multi-layer application environment, such resource-consuming operations have a particularly significant impact on system performance.

In multi-tier applications, the connection pool (Connection pooling) technology can significantly improve system performance. The connection pool means that when an application needs to call a database connection, database-related interfaces re-create a database connection by returning a database connection that is reused. In this way, applications can reduce database connection operations, especially in multi-tier environments, multiple clients can meet system requirements by sharing a small number of physical database connections. By using the connection pool technology, Java applications can not only improve the system performance, but also improve the measurable performance of the system.

The database connection pool runs in the background and the application code has no impact. In this case, the application must use the datasource object (an instance implementing the javax. SQL. datasource Interface) instead of the original drivermanager class to obtain the database connection method. A class implementing the javax. SQL. datasource interface can support or not support the database connection pool, but the code for obtaining the database connection is basically the same.

The Code is as follows:

A datasource object is usually registered on the JNDI Naming Service. The application can obtain the datasource object registered on the JNDI service in a standard way.

Context CTX = new initialcontext ();
Datasource DS = (datasource) CTX. Lookup ("JDBC/openbase ");

If the current datasource does not support the database connection pool, the application obtains a connection object corresponding to the physical database connection. If the current datasource object supports the database connection pool, the application automatically obtains the reused database connection instead of creating a new database connection. There is no difference in the usage of reused database connections and newly established database connections. Applications can access the database through reusable connections and perform data access operations. After the operation is completed, close () should be called explicitly to close the database connection.

Connection con = Ds. getconnection ("user", "PWD ");
Related database operations;
Con. Close ();

When the data connection is closed, the currently used database connection will not be physically closed, but will be put back into the database connection pool for reuse.

Database Connection Pool framework in jdbc3.0 specifications
The jdbc3.0 specification provides a framework to support the database connection pool. This framework only specifies how to support the implementation of the connection pool. The specific implementation of the Connection Pool JDBC 3.0 specification is not specified. This framework allows developers of different roles to implement database connection pools.

The jdbc3.0 specification shows that the implementation of a specific database connection pool can be divided into JDBC driver and application server. Any related work in JDBC driver-level implementation is implemented by the JDBC drvier developers of specific database vendors, that is, JDBC driver must support both the database connection pool and the database connection pool. In the Application Server-level database connection pool implementation, JDBC driver developers of specific database vendors and application server developers can work together to implement the database connection pool (but now most application server vendors have implemented the connection pool mechanism and specification are different ), the JDBC driver of a specific database vendor provides support for the database connection pool, while the specific application server vendor provides the specific implementation of the database connection pool.

The jdbc3.0 specification specifies the following classes and interfaces to support the implementation of the database connection pool.

Javax. SQL. connectionevent
Javax. SQL. connectionpooldatasource
Javax. SQL. pooledconnection
Javax. SQL. connectioneventlistener

Except javax. SQL. connectionevent is a class, and all others are interfaces.

This figure shows the location of related interfaces in a typical layer-3 environment.

At the database connection pool implementation level, JDBC driver developers of specific database vendors provide connection pool support, while the implementation of connection pools provided by specific application servers is complicated, other implementation levels can be considered as a simplified situation. The following describes the situation.

In this framework, there are two main user roles:

The JDBC driver developer of a specific database vendor.
Connection Pool developers in a specific application server

The following describes several key modules:

Driver vendor datasource:
Driver vendor must provide the specific implementation of a connectionpooldatasource interface. Through this interface, pooling vendor can get a pooledconnection object, so that the connection pool implemented by a third party can use a specific database vendor to obtain the database connection generated by the JDBC driver. The connectionpooldatasource interface role can be considered as the factory that generates the pooledconnection object.

Driver vendor pooledconnection:
Driver vendor must provide the class implemented by the standard pooledconnection interface, which allows pooling vendor to implement the connection pool based on the JDBC driver's support for the connection pool. A specific pooledconnection object represents a physical database connection. The connection object created by the pooledconnection object is only a handle pointing to the pooledconnection object. In the JDBC 3.0 connection pool implementation framework, the role played by the pooledconnection object can be regarded as the factory that generates the connection object.

Pooling vendor datasource:
Pooling vendor must implement the datasource interface, which is the entry point for interaction with the connection pool implementation module. Connectionpooldatasource creates a pooledconnection object as needed.

Pooling vendor connection cache:
This module is the specific implementation of pooling vendor on the connection pool. The JDBC 3.0 specification does not specify the interfaces to be implemented between the datasource object and the database connection pool, so the interaction between them is defined by pooling vendor. Generally, the specific implementation of a database connection pool includes one or more specific classes, but the connection pool implementation module must contain a class to implement the standard connectioneventlistener interface. When a pooledconnectiond object is closed or an exception occurs, the pooledconnection object will send a connectionevent object to the connectioneventlistener interface. The connection pool implementation module will disable or reuse the pooledconnection Based on the returned connectionevent object.

Connectionevent:
When the application calls connection. when close () tries to close the database connection, a notice must be sent to the connection pool implementation module, notifying you to reuse the current database physical connection (pooledconnection object. To enable the connection pool implementation module to get this "notice", the connection pool implementation module must implement the connectioneventlistener interface and register it as the listener of the pooledconnection object. The connection pool implementation module registers itself as a listener through the pooledconnection. addconnectioneventlistener () method.

In a typical three-tier environment, the specific call process is as follows:
When the application calls datasource. getconnection () to obtain a database connection.

The datasource object implemented by pooling vendor is searched in the connection pool to check whether there is a valid pooledconnection object. If there is an available pooledconnection in the connection pool, check it. If the current pooledconnection is available, use it.

If no pooledconnection object is available in the connection pool or the current pooledconnection object is incorrect, pooling vendor calls connectionpooldatasource. the getpooledconnection class creates a new pooledconnection object. In this case, the connectionpooldatasource implemented by driver vender will create a new pooledconnection object that meets the requirements and return it to the connection pool implementation module for management.

Then, pooling vendor will call pooledconnection. getconnection () to obtain a logical connection object. The logical connection object will be returned to the application as a normal connection object. This logical connection object is actually a handle of the pooledconnection object in the connection pool. When the connection pool is valid, the application calls datasource. getconnection () to obtain this handle. In short, the connection object used by the application is only the handle of the pooledconnection object of its creator.

The connection pool implementation module calls pooledconnection. addconnectioneventlistener () to register itself as a listener of the pooledconnection object. When the database connection needs to be reused or closed, the connection pool implementation module can be announced.

When the application calls connection. close () to close the database connection. In this case, a connectionevent object is created and returned to the connection pool implementation module. After receiving this Notice, the connection pool implementation module returns the pooledconnection object to the pool for reuse. Other roles cannot access pooledconnection during these processes. the close () method can only access the pooling vendor method. They use this method to operate the objects in the connection pool through pooledconnection. the close () method can close the physical database connection.