?
Basic principle of database connection pool
The traditional database connection mode (refers to the connection through DRIVERMANAGER and the basic implementation of DataSource), a database connection object corresponds to a physical database connection, the establishment of a database connection, and the system for consuming system resources, in the multilayer structure The action of this cost of resource in the application environment is particularly obvious. In a multi-layer structure, the connection pool can be apparent from the connection pool, which means that the connection pool means that when the application needs to call a database connection, the database is reused by returning. Database connections are replaced by re-creating a database connection. In this way, the application can reduce the database connection operation, especially in multi-layer environments, multiple clients can meet system requirements by sharing a small amount of physical database connections. By connecting pool technology Java applications not only improve system performance, but also improves measurable. The database connection pool is running in the background and there is no impact on the application's coding. The premise of this situation is that the application must replace the original DRIVERMANAGER class by the DataSource object (an instance of the Javax.Sql.DataSource interface) to obtain the database connection. A class that implements a Javax.SQL.DataSource interface can also support the database connection pool, but the code that gets the database connection is basically the same. The code is as follows: A DataSource object usually registers on the JNDI naming service, the application can get the DataSource object registered on the JNDI service by standard. CONTEXT CTX = New InitialContext (); DataSource DS = (DataSource) CTX.lookup ("JDBC / OpenBase"); if the current DataSource does not support the database connection pool, the application will get a Connection object corresponding to the physical database connection. If the current DataSource object supports the database connection pool, the application automatically gets reuse database connections without creating a new database connection. Reuse database connections and newly established database connections are not available. The application can access the data for the operation of accessing the data by reused access to the database, and the database connection should be explicitly invoked after the operation is completed. Connection con = DS.GetConnection ("User", "PWD"); related database operations; con.close (); When the data connection is turned off, the currently used database connection will not be physically closed, but back to Reuse in the database connection pool.
Database connection pool frame in JDBC3.0 specification
The JDBC3.0 specification provides a framework that supports the database connection pool, this framework only specifies how to support the implementation of the connection pool, and the specific implementation of the connection pool is not related to the relevant provisions. Through this framework, the developers of different roles can make the database connection pool. The implementation of the specific database connection pool can be divided into JDBC DRIVER-level and Application Server levels. Any related work in the implementation of the JDBC Driver level is implemented by the developers of a specific database vendor's JDBC Drvier, that is, JDBC Driver requires both support for database connection pools to implement specific implementations. The JDBC Driver developers and Application Server developers of the Database Connection Pool in the Application Server level are implemented to implement the implementation of the database connection pool (but now the mechanism and specifications of the connection pools implemented by most Application Server vendors " It is mentioned that there is a difference), in which a specific database vendor's JDBC Driver provides a database connection pool support and a specific Application Server vendor provides a 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 Co., Ltd. is a class in addition to javax.sql.connectionEvent, and other interfaces. JDBC3.0 connection chart of the pool frame
This figure can probably understand the location of the application in a typical three-layer environment. In the database connection pool implementation, the JDBC Driver developers of a particular database vendor provide connection pool support, while the specific Application Server provides connection pool implementation is more complicated, and other implementations can be considered as a simplified situation. This will be described below. There are mainly two user roles in this frame, which are: JDBC Driver developers of a specific database vendor, then referred to as connecting pool developers in Driver Vendor Specific Application Server, which will be referred to as Pooling Vendor
The UML map between the various interfaces and classes in the JDBC3.0 specification
The following is a detailed description of several critical modules: Driver Vendor DataSource: Driver Vendor must provide a concrete implementation of a ConnectionPoolDataSource interface, which can get a PooledConnection object through this interface Pooling Vendor, so that the connection pool implemented by a third party can use a specific database. Vendors get database connections generated by JDBC Driver. The role played by the ConnectionPoolDataSource interface here can be considered as a factory that produces the PooledConnection object. Driver Vendor PooledConnection: Driver Vendor must provide a class implemented by the standard PooledConnection interface, which allows Pooling Vendor to implement the connection pool based on JDBC Driver provides connection pool support. A concrete PooledConnection object represents a physical database connection; creating a Connection object by the PooledConnection object is just a handle pointing to the PooledConnetion object. The role of the PooledConnection object-played role in the framework in the JDBC 3.0 connection pool can be treated as a factory that produces the Connection object. Pooling Vendor DataSource: POOLING VENDOR must implement the DataSource interface, this interface is an entry point that interacts with the connection pool implementation module. CONNECTIONPOOLDATASOURCE creates the 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 interface between the DataSource object and the database connection pool implementation, so the interaction between them is defined by the pooling vendor. In general, a specific implementation of a database connection pool contains one or several specific classes, but must include a class implementation standard ConnectionEventListener interface in the connection pool implementation module. When a PooledConnectionD object is turned off or an exception, the PooledConnection object will send a ConnectionEventEvent object to the ConnectionEventListener interface, and the connection pool implementation module will turn off or reuse the PooledConnection according to the returned ConnectionEvent object. ConnectionEvent: When the connection pool is implemented, when the application calls connection.close () Attempts to turn off the database connection, you need to have an advertisement to connect to the connection pool implementation module, and the current database is reused for the current database physical connection (PooledConnection object). In order to enable the connecting pool implementation module to get this "notification", the connection pool implementation module must implement the ConnectionEventListener interface, and also register as a listener for the PooledConnection object. The connection pool implementation module is registered as a listener through the PooledConnection.addConnectionEventListener () method. Specific call flow in a typical three-layer environment:
