java和mysql实现过期检测的简单介绍

本文目录一览：

• 1、java处理mysql日期问题
• 2、JAVA连mysql
• 3、java连接mysql数据库超时的问题谁遇到过?

java处理mysql日期问题

你还能用util.date的格式存进去么？是sql.date吧

所以在取出来的时候，使用sql.date接收就行了

如果需要改变格式的话，先转换成字符串就好了

JAVA连mysql

查看了Mysql的文档，以及Connector/J的文档以及在线说明发现，出现这种异常的原因是：Mysql服务器默认的“wait_timeout”是8小时，也就是说一个connection空闲超过8个小时，Mysql将自动断开该 connection。这就是问题的所在，在C3P0 pools中的connections如果空闲超过8小时，Mysql将其断开，而C3P0并不知道该connection已经失效，如果这时有 Client请求connection，C3P0将该失效的Connection提供给Client，将会造成上面的异常。

上网搜索，在MySQL的论坛上找到一个办法，就是如果在执行sql语句的时候发生了上述异常，就将sql语句重新执行一次。

试验发现，这个办法对这个使用spring+hibernate的服务无效。

进一步搜索发现，MySQL官方不推荐使用autoReconnect=true，参见

需要另外找别的办法来解决这个问题。

由于问题产生的根本原因在于服务到数据库的连接长时间没活动，既然重新连接的办法无效，就可以尝试另外一种办法，就是反空闲。

自己写一个线程来反空闲的话，比较麻烦。

最后在网上找到一个办法。为hibernate配置连接池，推荐用c3p0，然后配置c3p0的反空闲设置idle_test_period，只要小于MySQL的wait timeout即可。

在hibernate.cfg.xml中增加下面几项：

!– configuration pool via c3p0–

property name=”hibernate.connection.provider_class”org.hibernate.connection.C3P0ConnectionProvider/property

property name=”c3p0.min_size”5/property

property name=”c3p0.max_size”30/property

property name=”c3p0.time_out”1800/property !– seconds –!– default: 0 —

property name=”c3p0.max_statement”50/property !– default: 0 —

property name=”c3p0.acquire_increment”1/property !– default: 1 —

property name=”c3p0.idle_test_period”120/property !– seconds –!– default: 0 —

property name=”c3p0.validate”true/property

修改完后测试，问题解决。

——————————————————–

DBCP连接池说明:

driverClassName

url

username

password

上面四个分别是驱动,连接字符串,用户名和密码

maxActive 连接池支持的最大连接数

maxIdle 连接池中最多可空闲maxIdle个连接

minIdle 连接池中最少空闲maxIdle个连接

initialSize 初始化连接数目

maxWait 连接池中连接用完时,新的请求等待时间,毫秒

timeBetweenEvictionRunsMillis timeBetweenEvictionRunsMillis和minEvictableIdleTimeMillis一起使用,每

timeBetweenEvictionRunsMillis毫秒秒检查一次连接池中空闲的连接,把空闲时间超过minEvictableIdleTimeMillis毫秒的连接断开,直到连接池中的连接数到minIdle为止

minEvictableIdleTimeMillis 连接池中连接可空闲的时间,毫秒

removeAbandoned true,false,是否清理removeAbandonedTimeout秒没有使用的活动连接,清理后并没有放回连接池

removeAbandonedTimeout 活动连接的最大空闲时间

logAbandoned true,false,连接池收回空闲的活动连接时是否打印消息

minEvictableIdleTimeMillis,removeAbandonedTimeout这两个参数针对的连接对象不一样,minEvictableIdleTimeMillis针对连接池中的连接对象,removeAbandonedTimeout针对未被close的活动连接.

c3p0连接池说明:

driverClass

jdbcUrl

user

password

minPoolSize

maxPoolSize

initialPoolSize

acquireIncrement 池中没有空闲连接时,一次请求获取的连接数

maxIdleTime 池中连接最大空闲时间

acquireRetryAttempts 获取连接失败后,重新尝试的次数

acquireRetryDelay 尝试连接间隔时间,毫秒

checkoutTimeout 等待连接时间,0为无限等待,毫秒

DebugUnreturnedConnectionStackTraces true,false,是否收回未返回的活动连接

unreturnedConnectionTimeout 活动连接的时间.

jdbcurl建议不要使用autoReconnect=true。

———————————————————————-

session.close();没有调用connection.close()吗？

如果你的Connection来自于连接池，他只不过被归还给池了，确实没有物理关闭，这是正常的结果。

若调用connection.close(), 此连接对象是关闭，还是没有关闭，只返回给了连接池 ?

那要看连接池的实现了。一般都是返回给连接池，因为新建连接的开销太大了。

创建一个SessionFactry就对应一个Connection,面SessionFactory中的Session是共享Connection .所以关闭Session对Connection没有影响的.

数据库连结池不过就是一个特殊的对象池而已。 对象池的作用就是避免你直接new资源性的对象，降低开销。把连结返回给连结池就是释放对该对象池中该Connection对象的引用，这样，这个对象可以给再次被别人使用。 你调用conn.close()，仅仅是释放了引用而已，不会关闭物理的连接。

connection对像在链接池中复写了close方法，所以并没有真正意义上的关闭。明白了吧。当然不同的链接池有不同的实现方法，connection只是一个接口，不同的链接池实现类是不一样的，只是我们感觉不到罢了。

java连接mysql数据库超时的问题谁遇到过?

推测你指的是mysql服务器的超时吧。默认情况8小时无访问mysql会断开连接。通过改配置文件可以改变这个值，但是实际测试效果不好。

mysql方面不好解决就在client端想办法，大多数链接池可以配置在取得链接时检测可用性(据说c3p0连接池可以自动解决，我用的dbcp需要配置)，比如ibatis可以在datasource配置加上property

name=”validationQuery”

value=”select

1

from

dual”/

property

name=”testOnBorrow”

value=”true”/