Mysql经典的“8小时问题”

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

Mysql经典的“8小时问题”。  在spring中配置数据源时,必须设定destroy-method=”close”属性,以便spring容器关闭时,数据源能正常关闭。

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

  如果数据库时mysql,如果数据源配置不当,则可能发生经典的“8小时问题”。原因是mysql在默认情况下如果发现一个连接的空闲时间超过8小时,会在数据库端自动关闭这个连接。而数据源不知道这个连接已经被数据库关闭,当他将这个“空闲”的连接交给DAO时,DAO就会报无法获取connection的异常。

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

  如果采用DBCP默认配置,testOnBorrow属性默认值为true,数据源在将连接交给DAO前,会检测这个连接是否是正常的,如果有问题,会再取一个连接,所以不会有8小时问题。如果每次在交给DAO时都检测连接的有效性,则会再高并发时造成性能问题,因为这造成了更多的数据库访问请求。

发表评论

电子邮件地址不会被公开。 必填项已用*标注