Realization of DBCP connection pool for Java connection to MySql

DBCP1.4 or 1.6 dependent jar package

Insert picture description here

DBCP parameter description

Insert picture description here

Insert picture description here
Insert picture description here

Code

DBToolls.java file

Insert picture description here
Insert picture description here
Test test.java
Insert picture description here

operation result

Insert picture description here

The jar package that DBCP2 or above depends on

Insert picture description here

DBCP2 configuration detailed instructions

Due to the version upgrade of the connection pool used by commons-dbcp, the database pool connection configuration in commons-dbcp2 has also changed. The specific parameter configuration instructions are as follows:

Common connection configuration

Insert picture description here

Data source connection quantity configuration

Insert picture description here
Tip: If you set the maxIdle value very low in a high-load system, you may find that a new connection is immediately closed when it is just created. This is because the active thread closes the connection faster than the thread that opens the connection, causing the number of idle connections to be greater than maxIdle. The most suitable configuration value for maxIdle in a high-load system is diverse, but the default value is a good starting point.

Transaction attribute configuration

Insert picture description here

Data source connection health check

Insert picture description here
Insert picture description here

Cache statement

Insert picture description here
This setting also affects the prepared statement pool. When an available statement pool is created for each connection, the prepared statements created by the following methods will be pooled.

public PreparedStatement prepareStatement(String sql)
public PreparedStatement prepareStatement(String sql, int resultSetType, int resultSetConcurrency)
Tip-make sure your connection will leave some resources for other statements. Pooled prepared statements may keep their cursors in the database, which may cause the cursors of the connection to go out of bounds, especially the value of maxOpenPreparedStatements is set to the default value (unlimited), and an application may open a large number for each connection Different prepared statements. To avoid this problem, maxOpenPreparedStatements should be set to a value less than the maximum number of cursors that the connection can open.
Insert picture description here
If access is allowed, use the following code structure: the
Insert picture description here
default value is false, which is a potentially risky operation, and improper use may cause very serious consequences. (In the case that the guard connection has been closed, close the underlying connection or continue to use it), you can use it with caution only when you need to directly access the unique extension of the driver.

NOTE: Except for the original one, do not close the underlying connection
Insert picture description here

Connection leak recovery

Insert picture description here

Code

DB2.java file

Insert picture description here
Insert picture description here
test.java file
Insert picture description here

Results of the

Insert picture description here
Add group for interview information 748620413

Guess you like

Origin blog.csdn.net/yueyunyin/article/details/102485910