8 hours for MySQL

An 8 hour question about MySQL came up in the project.

Recently, the problem of database connection being closed occurred during the project testing process.

Phenomenon:
When the first few orders are tested in the morning, the connection close will be reported, and the next day will be normal.

Preliminary exploration:
After using C3P0, it is natural to think why C3P0 will use the close connection for the project, because C3P0 itself has a mechanism to check whether the connection is valid. Naturally, I thought whether there was a problem with the configuration. As a result, all the options were configured, and there were problems in the local test.
Local test test scenario:
1. The 8-hour connection of MySQL is invalid and changed to 2 minutes.
2. C3P0 configures all the configurations related to checking the connection.
Disappointingly, none of them worked.

Further: Has the bug of C3P0 been triggered and changed to Ali's connection pool? , but the idea was only fleeting.

Finally: there is no way, go back and study the code line by line, analyze the business, and finally find that a problem is found in the code that has nothing to do with the database.

Cause: In a thread, a connection to C3P0 was acquired. When fetching data from the cache queue in the business code, if there is no data in the queue, the thread is blocked! In this way, when there is no data in the queue for a long time (in the test environment, colleagues did not submit orders after get off work), this data point exceeds the 8-hour setting of MySQL. After 8 hours, the MySQL check mechanism checks that the connection has no data. interact. The connection will be closed. This is the behavior of MySQL not to notify the connection pool. In our system, because the connection is always occupied by the thread, C3P0 will not check whether it is valid (because C3P0 thinks you have been using the connection). In this way, C3P0 thinks it can be used, and MySQL has actually been closed. When the test colleague sends data to the queue in the morning, the thread is unblocked, and when the held connection is used to operate the database later, a close error will be reported at this time.

Summary: 1. Don't easily doubt the open source tools you use, because 99.99% of the problems you encounter are problems with your own code.
      2. Do not block the thread as a last resort. Even if the blocking method is used, a timeout must be added.