A simpler connection pool leak solution

Because it is a financial company, it is inconvenient to disclose the code and system name.

Background description

1) The UAT environment of a system pushes the data to the B system.

650) this.width=650; "src=" Http://s4.51cto.com/wyfs02/M02/7F/D2/wKiom1cuKVmAGXWVAAAEfSfIr6A654.png "title=" Picture 1.png "alt=" Wkiom1cukvmagxwvaaaefsfir6a654.png "/>

2) because the system does not use the message middleware decoupling, the B system's connection pool leakage caused a system function is also affected.

3) There is no problem with the production environment.

4) The server is outsourced to IBM and is not authorized to view the JVM's dump and is not authorized to log on to the server machine.

5) The connection pool is not immediately completely leaked, but gradually eaten.

Adoption of the technical framework:

Seam+spring+hibernate

Database Oracle RAC

Diagnosis:

Because the production environment did not find the problem, the approximate rate can be determined to be due to data problems. From the data provided by the DBE team, almost all of the connection sessions were executed by one of the same SQL (Hibernate generation) after the card was killed.

1) traced to SQL, traced from SQL to hibernate, and then found the corresponding code. (Fortunately, this SQL only appears on one of our code, it is easy to lock up the suspected area of disclosure)

650) this.width=650; "src=" Http://s5.51cto.com/wyfs02/M00/7F/D2/wKiom1cuLMSCOmXzAAAwnUi9x_U781.png "title=" Picture 2.png "alt=" Wkiom1culmscomxzaaawnui9x_u781.png "/>

Since all the session cards are in a, it is decided that the process of checking the data should be problematic. The view is then viewed.

Reason for locking:

The red block examines the data in the code, throwing a run-time exception.

Unfortunately, external manually managed transactions do not have to do a try catch to rollback a transaction operation. The exception is handled by the thread pool, and the connection is not returned to the connection pool.

Finally, to clarify, this code is not written by me .....

The data provided by the DBE team is a great help in cases where the JVM cannot be viewed in real time.

It is also a good starting point to track the last SQL executed by the leaked session.

This article from "Tech Doc" blog, declined reprint!

A simpler connection pool leak solution