Assuming your database is MySQL, a classic "8-hour problem" can occur if the data source is misconfigured. The reason is that MySQL, by default, will automatically close this connection on the database side if it finds that a connection has been idle for more than 8 hours. The data source does not know that the connection is closed, and when it returns the useless connection to a DAO, DAO will report that it cannot get the connection exception.
If the default configuration of DBCP is used, the data source will detect if the connection is good before handing it over to DAO, because the default value of the Testonborrow property is true, and if there is a problem with the connection (it is closed on the database side), a different connection will be taken to the DAO. So there is no "8-hour problem". If the validity of the connection is detected each time the connection is given to DAO, there will be a performance problem in high concurrency applications because it will require more database access requests.
One recommended and efficient way is to set Testonborrow to false and set Testwhileidle to True, and then set the Testbetweenevictionrunsmillis value (less than 8 hours). Those connections that are shut down by MySQL are not cleared out and the "8-hour problem" is avoided.
Of course, MySQL itself can also adjust interactive-timeout (in seconds) to configure parameters to change the expiration time of an idle connection. Therefore, when setting the Timebetweenevictionrunsmmillis value, you must first know the maximum expiration time of the idle connection for MySQL.
C3P0 for effective connection detection, refer to the DBCP configuration method.
Mysql "8-hour problem"