Mysql经典的“8小时问题”

MySQL 的默认设置下,当一个连接的空闲时间超过8小时后,MySQL 就会断开该连接,而 c3p0 连接池则以为该被断开的连接依然有效。

假设你的数据库是mysql，如果数据源配置不当，将可能发生经典的“8小时问题”。原因是mysql在默认情况下，如果发现一个连接的空闲时间超过8小时，将会在数据库端自动关闭这个连接。而数据源并不知道这个连接已经关闭了，当它将这个无用的连接返回给某个dao时，dao就会报无法获取connection异常。

    如果采用dbcp的默认配置，由于testOnBorrow属性的默认值是true，数据源在将连接交给dao前，会事先检测这个连接是否是好的，如果连接有问题（在数据库端被关闭），则会取一个其他的连接给dao。所以并不会有“8小时问题”。如果每次将连接交给dao时都检测连接的有效性，在高并发的应用中将会带来性能的问题，因为它会需要更多的数据库访问请求。

    一种推荐的高效的方式是：将testOnBorrow设置为false，而将“testWhileIdle”设置为true，再设置好testBetweenEvictionRunsMillis值（小于8小时）。那些被mysql关闭的连接就可以别清除出去，避免“8小时问题”。

    当然，mysql本身也能调整interactive-timeout（以秒为单位）配置参数，更改空闲连接的过期时间。所以，在设置timeBetweenEvictionRunsmMillis值时，必须首先获知mysql的空闲连接的最大过期时间。

    c3p0对于有效连接的检测，请参照dbcp配置方式。