前两天，项目部某项目使用websphere连接池出问题，在系统运行一定时候后，无法从连接池中获取Connection了。
这已经是这一年多来，我 接手的不是第八、就是是第九个类似问题了。这似乎不是一个很复杂的问题，但是确实在项目应用部署中却频繁出现的问题。
这些问题都有很多比较明显的共同点，也大多集中在如下情况中：
（1）连接池和数据库服务器，表现为大量sleeping connection未释放
（2）应用程序获取的连接为stale connection（无效连接）
（3）数据库服务器重起后，应用服务器也需要重起
在应用部署过程中，为了在获取尽可能高效的数据库连接处理，采用应用服务器的连接池，这是个正确的选择。几乎所有的项目组都会这么做，而且配置和应用也都没有什么难度。—— 但是很不幸运，正是很多人所寄予厚望的应用服务器连接池，却很容易忽悠大家，在系统运行运行一段时间后，会毫无情面的抛出获取连接超时、失败，或者报告这是一个无效的连接······等等匪夷所思的问题。
正是 连接池的“池缓存”的功能，让数据库连接能够高效的利用；但也正是“池缓存”的功能，让这些问题不断的暴露出来，正所谓“成也萧何，败也萧何”。
因为在池中缓冲的那些“Connection”，有很多是刚刚被Client端释放，但是连接池本身来却没有去close它们，而是依然“维持”连接，以期等待后续其他Client的请求。—— 但是就是这么一段可能并不长的时间，却有着很多潜在的危险：此时网络有一定的不稳定，池中原本与数据库保持连接的Connection，却因此而中断了通讯——但是此时连接池依然以为这个一个有效的Connection返回给了Client······结果大家可想而知。
真实的原因可能比这更加复杂，也更多种情况，也因此就造成了上面那些种异常的发生。
其实，解决这些异常，本身不是很难，而且几乎当前所有的应用服务器连接池都提供了支持，甚至包括很多开源的连接池组件，比如Apache DBCP。
解决诸如此类连接池异常问题，把握如下两个关键点即可：
（1）打开应用服务器连接池的“续连接支持开关”，就是说，在把池中的Connection对象返给Client端的时候（或从Client端回收的时候）做一次有效性验证，以确定这是一个有效连接。
（2）打开连接池的无效连接定期回收机制，就是说，让连接池每经过一段时间，就对连接池中的那些已经无效的连接进行回收。（但切记，这样的回收操作尽量不要过于频繁）
下面就拿Weblogic和WebShpere两款应用服务来说明，如何设置它们连接池的“续连接”和“回收”机制
（一）WebLogic Application Server
（1）weblogic的连接验证设置：
WLS里设置连接的检查，一个是获取连接的时候检查该连接是否有效，另外一个就是释放连接的时候检查。这两个检查在配置连接池的时候都是可以设置的。
TestConnectionsOnReserve 从连接池获取连接后是否进行有效性测试 True/false
RefreshMinutes parameter 设定connection pool的刷新时间 刷新的时间间隔
Test Table Name 测试的表名，也可以指定SQL 表名或者是SQL
（2）weblogic的无效连接回收时间设置：
通过设置weblogic-ra.xml中的inactive-connection-timeout-seconds，weblogic连接池会根据设置，主动关闭那些超时idle的connection。关于weblogic-ra.xm的文档如下：
http://e-docs.bea.com/wls/docs81/jconnector/dtdappen.html#1031211
（二）Webshpere Application Server
（1）首先需要通过修改配置文件来启动预连接测试功能。主要是修改$WAS_HOME/properties/j2c.properties 配置文件，修改后重新启动服务器。
修改advanced-connection-properties 元素，jdbc/DataSource应替换为用户的数据源的JNDI名称。
testConnection必须设为true，以表明用户启动预连接测试功能。
testConnectionRetryInterval为预连接测试失败后重试间隔的秒数。
（2）其次需要配置预连接测试语句：
WebSphere的管理控制台，定位Resources > JDBC_provider > Data Sources > data_source > Custom Properties 。
新建一个用户属性，指定 preTestSQLString (大小写敏感) 作为属性名，指定要测试的SQL语句作为属性值。
注：这条SQL语句是用来检查连接是否有效的，必须用有效的SQL语句，并且需要执行速度最快，占用资源最少。每次用户发出数据库连接请求时WebSphere会先调用这条语句做连接尝试。DB2数据库用户可以选择SELECT 1 FROM SYSIBM.SYSDUMMY1 。Oracle用户可以选择SELECT USER FROM DUAL作为测试连接语句。
但是，在应用过程中，不代表所有的应用连接池部署都需要开启“续连接”或“回收”，这是因为，续连接回造成每次获取连接的时间会无形的增加，而“回收”操作则会比较占用资源，如果过于频繁，则影响了系统响应效率。
所以，这两项连接池的服务，是否一定需要开启，则要根据应用特点来分别对待了。
前两天，项目部某项目使用websphere连接池出问题，在系统运行一定时候后，无法从连接池中获取Connection了。
这已经是这一年多来，我 接手的不是第八、就是是第九个类似问题了。这似乎不是一个很复杂的问题，但是确实在项目应用部署中却频繁出现的问题。
这些问题都有很多比较明显的共同点，也大多集中在如下情况中：
（1）连接池和数据库服务器，表现为大量sleeping connection未释放
（2）应用程序获取的连接为stale connection（无效连接）
（3）数据库服务器重起后，应用服务器也需要重起
在应用部署过程中，为了在获取尽可能高效的数据库连接处理，采用应用服务器的连接池，这是个正确的选择。几乎所有的项目组都会这么做，而且配置和应用也都没有什么难度。—— 但是很不幸运，正是很多人所寄予厚望的应用服务器连接池，却很容易忽悠大家，在系统运行运行一段时间后，会毫无情面的抛出获取连接超时、失败，或者报告这是一个无效的连接······等等匪夷所思的问题。
正是 连接池的“池缓存”的功能，让数据库连接能够高效的利用；但也正是“池缓存”的功能，让这些问题不断的暴露出来，正所谓“成也萧何，败也萧何”。
因为在池中缓冲的那些“Connection”，有很多是刚刚被Client端释放，但是连接池本身来却没有去close它们，而是依然“维持”连接，以期等待后续其他Client的请求。—— 但是就是这么一段可能并不长的时间，却有着很多潜在的危险：此时网络有一定的不稳定，池中原本与数据库保持连接的Connection，却因此而中断了通讯——但是此时连接池依然以为这个一个有效的Connection返回给了Client······结果大家可想而知。
真实的原因可能比这更加复杂，也更多种情况，也因此就造成了上面那些种异常的发生。
其实，解决这些异常，本身不是很难，而且几乎当前所有的应用服务器连接池都提供了支持，甚至包括很多开源的连接池组件，比如Apache DBCP。
解决诸如此类连接池异常问题，把握如下两个关键点即可：
（1）打开应用服务器连接池的“续连接支持开关”，就是说，在把池中的Connection对象返给Client端的时候（或从Client端回收的时候）做一次有效性验证，以确定这是一个有效连接。
（2）打开连接池的无效连接定期回收机制，就是说，让连接池每经过一段时间，就对连接池中的那些已经无效的连接进行回收。（但切记，这样的回收操作尽量不要过于频繁）
下面就拿Weblogic和WebShpere两款应用服务来说明，如何设置它们连接池的“续连接”和“回收”机制
（一）WebLogic Application Server
（1）weblogic的连接验证设置：
WLS里设置连接的检查，一个是获取连接的时候检查该连接是否有效，另外一个就是释放连接的时候检查。这两个检查在配置连接池的时候都是可以设置的。
TestConnectionsOnReserve 从连接池获取连接后是否进行有效性测试 True/false
RefreshMinutes parameter 设定connection pool的刷新时间 刷新的时间间隔
Test Table Name 测试的表名，也可以指定SQL 表名或者是SQL
（2）weblogic的无效连接回收时间设置：
通过设置weblogic-ra.xml中的inactive-connection-timeout-seconds，weblogic连接池会根据设置，主动关闭那些超时idle的connection。关于weblogic-ra.xm的文档如下：
http://e-docs.bea.com/wls/docs81/jconnector/dtdappen.html#1031211
（二）Webshpere Application Server
（1）首先需要通过修改配置文件来启动预连接测试功能。主要是修改$WAS_HOME/properties/j2c.properties 配置文件，修改后重新启动服务器。
修改advanced-connection-properties 元素，jdbc/DataSource应替换为用户的数据源的JNDI名称。
testConnection必须设为true，以表明用户启动预连接测试功能。
testConnectionRetryInterval为预连接测试失败后重试间隔的秒数。
（2）其次需要配置预连接测试语句：
WebSphere的管理控制台，定位Resources > JDBC_provider > Data Sources > data_source > Custom Properties 。
新建一个用户属性，指定 preTestSQLString (大小写敏感) 作为属性名，指定要测试的SQL语句作为属性值。
注：这条SQL语句是用来检查连接是否有效的，必须用有效的SQL语句，并且需要执行速度最快，占用资源最少。每次用户发出数据库连接请求时WebSphere会先调用这条语句做连接尝试。DB2数据库用户可以选择SELECT 1 FROM SYSIBM.SYSDUMMY1 。Oracle用户可以选择SELECT USER FROM DUAL作为测试连接语句。
但是，在应用过程中，不代表所有的应用连接池部署都需要开启“续连接”或“回收”，这是因为，续连接回造成每次获取连接的时间会无形的增加，而“回收”操作则会比较占用资源，如果过于频繁，则影响了系统响应效率。
所以，这两项连接池的服务，是否一定需要开启，则要根据应用特点来分别对待了。
前两天，项目部某项目使用websphere连接池出问题，在系统运行一定时候后，无法从连接池中获取Connection了。
这已经是这一年多来，我 接手的不是第八、就是是第九个类似问题了。这似乎不是一个很复杂的问题，但是确实在项目应用部署中却频繁出现的问题。
这些问题都有很多比较明显的共同点，也大多集中在如下情况中：
（1）连接池和数据库服务器，表现为大量sleeping connection未释放
（2）应用程序获取的连接为stale connection（无效连接）
（3）数据库服务器重起后，应用服务器也需要重起
在应用部署过程中，为了在获取尽可能高效的数据库连接处理，采用应用服务器的连接池，这是个正确的选择。几乎所有的项目组都会这么做，而且配置和应用也都没有什么难度。—— 但是很不幸运，正是很多人所寄予厚望的应用服务器连接池，却很容易忽悠大家，在系统运行运行一段时间后，会毫无情面的抛出获取连接超时、失败，或者报告这是一个无效的连接······等等匪夷所思的问题。
正是 连接池的“池缓存”的功能，让数据库连接能够高效的利用；但也正是“池缓存”的功能，让这些问题不断的暴露出来，正所谓“成也萧何，败也萧何”。
因为在池中缓冲的那些“Connection”，有很多是刚刚被Client端释放，但是连接池本身来却没有去close它们，而是依然“维持”连接，以期等待后续其他Client的请求。—— 但是就是这么一段可能并不长的时间，却有着很多潜在的危险：此时网络有一定的不稳定，池中原本与数据库保持连接的Connection，却因此而中断了通讯——但是此时连接池依然以为这个一个有效的Connection返回给了Client······结果大家可想而知。
真实的原因可能比这更加复杂，也更多种情况，也因此就造成了上面那些种异常的发生。
其实，解决这些异常，本身不是很难，而且几乎当前所有的应用服务器连接池都提供了支持，甚至包括很多开源的连接池组件，比如Apache DBCP。
解决诸如此类连接池异常问题，把握如下两个关键点即可：
（1）打开应用服务器连接池的“续连接支持开关”，就是说，在把池中的Connection对象返给Client端的时候（或从Client端回收的时候）做一次有效性验证，以确定这是一个有效连接。
（2）打开连接池的无效连接定期回收机制，就是说，让连接池每经过一段时间，就对连接池中的那些已经无效的连接进行回收。（但切记，这样的回收操作尽量不要过于频繁）
下面就拿Weblogic和WebShpere两款应用服务来说明，如何设置它们连接池的“续连接”和“回收”机制
（一）WebLogic Application Server
（1）weblogic的连接验证设置：
WLS里设置连接的检查，一个是获取连接的时候检查该连接是否有效，另外一个就是释放连接的时候检查。这两个检查在配置连接池的时候都是可以设置的。
TestConnectionsOnReserve 从连接池获取连接后是否进行有效性测试 True/false
RefreshMinutes parameter 设定connection pool的刷新时间 刷新的时间间隔
Test Table Name 测试的表名，也可以指定SQL 表名或者是SQL
（2）weblogic的无效连接回收时间设置：
通过设置weblogic-ra.xml中的inactive-connection-timeout-seconds，weblogic连接池会根据设置，主动关闭那些超时idle的connection。关于weblogic-ra.xm的文档如下：
http://e-docs.bea.com/wls/docs81/jconnector/dtdappen.html#1031211
（二）Webshpere Application Server
（1）首先需要通过修改配置文件来启动预连接测试功能。主要是修改$WAS_HOME/properties/j2c.properties 配置文件，修改后重新启动服务器。
修改advanced-connection-properties 元素，jdbc/DataSource应替换为用户的数据源的JNDI名称。
testConnection必须设为true，以表明用户启动预连接测试功能。
testConnectionRetryInterval为预连接测试失败后重试间隔的秒数。
（2）其次需要配置预连接测试语句：
WebSphere的管理控制台，定位Resources > JDBC_provider > Data Sources > data_source > Custom Properties 。
新建一个用户属性，指定 preTestSQLString (大小写敏感) 作为属性名，指定要测试的SQL语句作为属性值。
注：这条SQL语句是用来检查连接是否有效的，必须用有效的SQL语句，并且需要执行速度最快，占用资源最少。每次用户发出数据库连接请求时WebSphere会先调用这条语句做连接尝试。DB2数据库用户可以选择SELECT 1 FROM SYSIBM.SYSDUMMY1 。Oracle用户可以选择SELECT USER FROM DUAL作为测试连接语句。
但是，在应用过程中，不代表所有的应用连接池部署都需要开启“续连接”或“回收”，这是因为，续连接回造成每次获取连接的时间会无形的增加，而“回收”操作则会比较占用资源，如果过于频繁，则影响了系统响应效率。
所以，这两项连接池的服务，是否一定需要开启，则要根据应用特点来分别对待了。
前两天，项目部某项目使用websphere连接池出问题，在系统运行一定时候后，无法从连接池中获取Connection了。
这已经是这一年多来，我 接手的不是第八、就是是第九个类似问题了。这似乎不是一个很复杂的问题，但是确实在项目应用部署中却频繁出现的问题。
这些问题都有很多比较明显的共同点，也大多集中在如下情况中：
（1）连接池和数据库服务器，表现为大量sleeping connection未释放
（2）应用程序获取的连接为stale connection（无效连接）
（3）数据库服务器重起后，应用服务器也需要重起
在应用部署过程中，为了在获取尽可能高效的数据库连接处理，采用应用服务器的连接池，这是个正确的选择。几乎所有的项目组都会这么做，而且配置和应用也都没有什么难度。—— 但是很不幸运，正是很多人所寄予厚望的应用服务器连接池，却很容易忽悠大家，在系统运行运行一段时间后，会毫无情面的抛出获取连接超时、失败，或者报告这是一个无效的连接······等等匪夷所思的问题。
正是 连接池的“池缓存”的功能，让数据库连接能够高效的利用；但也正是“池缓存”的功能，让这些问题不断的暴露出来，正所谓“成也萧何，败也萧何”。
因为在池中缓冲的那些“Connection”，有很多是刚刚被Client端释放，但是连接池本身来却没有去close它们，而是依然“维持”连接，以期等待后续其他Client的请求。—— 但是就是这么一段可能并不长的时间，却有着很多潜在的危险：此时网络有一定的不稳定，池中原本与数据库保持连接的Connection，却因此而中断了通讯——但是此时连接池依然以为这个一个有效的Connection返回给了Client······结果大家可想而知。
真实的原因可能比这更加复杂，也更多种情况，也因此就造成了上面那些种异常的发生。
其实，解决这些异常，本身不是很难，而且几乎当前所有的应用服务器连接池都提供了支持，甚至包括很多开源的连接池组件，比如Apache DBCP。
解决诸如此类连接池异常问题，把握如下两个关键点即可：
（1）打开应用服务器连接池的“续连接支持开关”，就是说，在把池中的Connection对象返给Client端的时候（或从Client端回收的时候）做一次有效性验证，以确定这是一个有效连接。
（2）打开连接池的无效连接定期回收机制，就是说，让连接池每经过一段时间，就对连接池中的那些已经无效的连接进行回收。（但切记，这样的回收操作尽量不要过于频繁）
下面就拿Weblogic和WebShpere两款应用服务来说明，如何设置它们连接池的“续连接”和“回收”机制
（一）WebLogic Application Server
（1）weblogic的连接验证设置：
WLS里设置连接的检查，一个是获取连接的时候检查该连接是否有效，另外一个就是释放连接的时候检查。这两个检查在配置连接池的时候都是可以设置的。
TestConnectionsOnReserve 从连接池获取连接后是否进行有效性测试 True/false
RefreshMinutes parameter 设定connection pool的刷新时间 刷新的时间间隔
Test Table Name 测试的表名，也可以指定SQL 表名或者是SQL
（2）weblogic的无效连接回收时间设置：
通过设置weblogic-ra.xml中的inactive-connection-timeout-seconds，weblogic连接池会根据设置，主动关闭那些超时idle的connection。关于weblogic-ra.xm的文档如下：
http://e-docs.bea.com/wls/docs81/jconnector/dtdappen.html#1031211
（二）Webshpere Application Server
（1）首先需要通过修改配置文件来启动预连接测试功能。主要是修改$WAS_HOME/properties/j2c.properties 配置文件，修改后重新启动服务器。
修改advanced-connection-properties 元素，jdbc/DataSource应替换为用户的数据源的JNDI名称。
testConnection必须设为true，以表明用户启动预连接测试功能。
testConnectionRetryInterval为预连接测试失败后重试间隔的秒数。
（2）其次需要配置预连接测试语句：
WebSphere的管理控制台，定位Resources > JDBC_provider > Data Sources > data_source > Custom Properties 。
新建一个用户属性，指定 preTestSQLString (大小写敏感) 作为属性名，指定要测试的SQL语句作为属性值。
注：这条SQL语句是用来检查连接是否有效的，必须用有效的SQL语句，并且需要执行速度最快，占用资源最少。每次用户发出数据库连接请求时WebSphere会先调用这条语句做连接尝试。DB2数据库用户可以选择SELECT 1 FROM SYSIBM.SYSDUMMY1 。Oracle用户可以选择SELECT USER FROM DUAL作为测试连接语句。
但是，在应用过程中，不代表所有的应用连接池部署都需要开启“续连接”或“回收”，这是因为，续连接回造成每次获取连接的时间会无形的增加，而“回收”操作则会比较占用资源，如果过于频繁，则影响了系统响应效率。
所以，这两项连接池的服务，是否一定需要开启，则要根据应用特点来分别对待了。