Hutchison mysql database connection process once the investigation is not closed issue

In some projects due to some special reasons still retains a display of database connection (Connection), commit the transaction, the transaction is rolled back, close the connection and other operations; close the connection which is relatively easy to ignore the problem and more difficult in the early discovery.

How do I troubleshoot connectivity issues is not closed? First is proposed 3W:

1.What?

  Database connection tcp connection is established between the application server and database, you need to manually shut down after getting the connection and operation in order to free up resources, just like file streams, resources are limited.

2.Why?

  Connection does not lead to the release of the connection pool connection can not be recycled, and then gradually fill the database connection, the database until the maximum number of connections and settings beyond denial of service, it is obvious this is not acceptable; the same time as the database connection is tcp connection, the connection is not released It will take tcp connection between the application server and database server, in some cases can lead to can not cope with bursty traffic (already not enough tcp connection).

3.How?

  Connection.close call display () closes the connection management connection or by spring.

My troubleshooting steps

1. scan code

  Since the connection is opened and closed connected to the display, the scan code file by obtaining the number of times each java file open connection times and connection is closed, if the number of connection close <open connection times, then it is possible here code is not the connection is closed, it can be further investigation.

  However, because each developer code style inconsistent, some such connection some Conn; some open connection, if-else inside each closed secondary external connector, etc., so the scanned code may not be accurate.

2. Database-level investigation

  If the connection is not closed, it will not be submitted to the transaction; transaction table provided by mysql and after opening performance_schema thread table can be positioned sql uncommitted transaction execution, reverse lookup code based sql, to locate the problem.

  The following test procedure simulated by a

  

 

 

   Code execution, after execution, the main thread waits

  

 

  View mysql transaction table, get thread_id (in fact processlist_id, see below)

  

 

  According processlist_id inquiry performance_schema thread information

  

 

 

 

   According thread_id specific sql query

  

 

  Then reverse lookup is based sql code ...

 

Guess you like

Origin www.cnblogs.com/zhya/p/11447978.html