一直发现系统中调用sh脚本重启系统中某些服务后系统会莫名奇妙的报错,由于开发环境在windows下,所以没办法直接跟踪,后来查看tomcat日志发现系统出错是在重启服务成功后记录日志时,google了很久发现该问题是由于sh脚本执行时间比较长,数据库连接已经被连接池回收,导致写数据库时出现了异常:com.mysql.jdbc.communicationsException:Communicatios link failure。网上有资料说proxool连接池解决了这个问题,但我们系统中本来就是用的该连接池,改了一下午配置文件始终未解决该问题;系统再次启动时进入proxool后端统计界面时发现了该连接池的一个属性test-before-use,该属性默认为false的,在配置文件中将该属性配置为true后重新发布工程测试,ok一切正常。以下为proxool的属性及说明:
fatal-sql-exception: 它是一个逗号分割的信息片段.当一个SQL异常发生时,他的异常信息将与这个信息片段进行比较.如果在片段中存在,那么这个异常将被认为是个致命错误(Fatal SQL Exception ).这种情况下,数据库连接将要被放弃.无论发生什么,这个异常将会被重掷以提供给消费者.用户最好自己配置一个不同的异常来抛出.
fatal-sql-exception-wrapper-class:正如上面所说,你最好配置一个不同的异常来重掷.利用这个属性,用户可以包装SQLException,使他变成另外一个异常.这个异常或者继承SQLException或者继承字RuntimeException.proxool自带了2个实现:'org.logicalcobwebs.proxool.FatalSQLException' 和'org.logicalcobwebs.proxool.FatalRuntimeException' .后者更合适.
house-keeping-sleep-time: house keeper 保留线程处于睡眠状态的最长时间,house keeper 的职责就是检查各个连接的状态,并判断是否需要销毁或者创建.
house-keeping-test-sql: 如果发现了空闲的数据库连接.house keeper 将会用这个语句来测试.这个语句最好非常快的被执行.如果没有定义,测试过程将会被忽略。
injectable-connection-interface: 允许proxool实现被代理的connection对象的方法.
injectable-statement-interface: 允许proxool实现被代理的Statement 对象方法.
injectable-prepared-statement-interface: 允许proxool实现被代理的PreparedStatement 对象方法.
injectable-callable-statement-interface: 允许proxool实现被代理的CallableStatement 对象方法.
jmx: 略
jmx-agent-id: 略
jndi-name: 数据源的名称
maximum-active-time: 如果housekeeper 检测到某个线程的活动时间大于这个数值.它将会杀掉这个线程.所以确认一下你的服务器的带宽.然后定一个合适的值.默认是5分钟.
maximum-connection-count: 最大的数据库连接数.
maximum-connection-lifetime: 一个线程的最大寿命.
minimum-connection-count: 最小的数据库连接数
overload-without-refusal-lifetime: 略
prototype-count: 连接池中可用的连接数量.如果当前的连接池中的连接少于这个数值.新的连接将被建立(假设没有超过最大可用数).例如.我们有3个活动连接2个可用连接,而我们的prototype-count是4,那么数据库连接池将试图建立另外2个连接.这和 minimum-connection-count不同. minimum-connection-count把活动的连接也计算在内.prototype-count 是spare connections 的数量.
recently-started-threshold: 略
simultaneous-build-throttle: 略
statistics: 连接池使用状况统计。 参数“10s,1m,1d”
statistics-log-level: 日志统计跟踪类型。 参数“ERROR”或 “INFO”
test-before-use: 使用前测试该连接是否可用,会产生效率问题。
test-after-use: 用后测试
trace: 如果为true,那么每个被执行的SQL语句将会在执行期被log记录(DEBUG LEVEL).你也可以注册一个ConnectionListener (参看ProxoolFacade)得到这些信息.
verbose: 详细信息设置。 参数 bool 值
fatal-sql-exception: 它是一个逗号分割的信息片段.当一个SQL异常发生时,他的异常信息将与这个信息片段进行比较.如果在片段中存在,那么这个异常将被认为是个致命错误(Fatal SQL Exception ).这种情况下,数据库连接将要被放弃.无论发生什么,这个异常将会被重掷以提供给消费者.用户最好自己配置一个不同的异常来抛出.
fatal-sql-exception-wrapper-class:正如上面所说,你最好配置一个不同的异常来重掷.利用这个属性,用户可以包装SQLException,使他变成另外一个异常.这个异常或者继承SQLException或者继承字RuntimeException.proxool自带了2个实现:'org.logicalcobwebs.proxool.FatalSQLException' 和'org.logicalcobwebs.proxool.FatalRuntimeException' .后者更合适.
house-keeping-sleep-time: house keeper 保留线程处于睡眠状态的最长时间,house keeper 的职责就是检查各个连接的状态,并判断是否需要销毁或者创建.
house-keeping-test-sql: 如果发现了空闲的数据库连接.house keeper 将会用这个语句来测试.这个语句最好非常快的被执行.如果没有定义,测试过程将会被忽略。
injectable-connection-interface: 允许proxool实现被代理的connection对象的方法.
injectable-statement-interface: 允许proxool实现被代理的Statement 对象方法.
injectable-prepared-statement-interface: 允许proxool实现被代理的PreparedStatement 对象方法.
injectable-callable-statement-interface: 允许proxool实现被代理的CallableStatement 对象方法.
jmx: 略
jmx-agent-id: 略
jndi-name: 数据源的名称
maximum-active-time: 如果housekeeper 检测到某个线程的活动时间大于这个数值.它将会杀掉这个线程.所以确认一下你的服务器的带宽.然后定一个合适的值.默认是5分钟.
maximum-connection-count: 最大的数据库连接数.
maximum-connection-lifetime: 一个线程的最大寿命.
minimum-connection-count: 最小的数据库连接数
overload-without-refusal-lifetime: 略
prototype-count: 连接池中可用的连接数量.如果当前的连接池中的连接少于这个数值.新的连接将被建立(假设没有超过最大可用数).例如.我们有3个活动连接2个可用连接,而我们的prototype-count是4,那么数据库连接池将试图建立另外2个连接.这和 minimum-connection-count不同. minimum-connection-count把活动的连接也计算在内.prototype-count 是spare connections 的数量.
recently-started-threshold: 略
simultaneous-build-throttle: 略
statistics: 连接池使用状况统计。 参数“10s,1m,1d”
statistics-log-level: 日志统计跟踪类型。 参数“ERROR”或 “INFO”
test-before-use: 使用前测试该连接是否可用,会产生效率问题。
test-after-use: 用后测试
trace: 如果为true,那么每个被执行的SQL语句将会在执行期被log记录(DEBUG LEVEL).你也可以注册一个ConnectionListener (参看ProxoolFacade)得到这些信息.
verbose: 详细信息设置。 参数 bool 值