- sleepTime：PoolKeeper检测时间间隔
- lifeTime：连接生命周期（上次访问时间-当前时间）
- deadLockMaxWait(：超过最大连接之后的调用getConnection的等待时间
- deadLockRetryWait：超过最大连接之后的调用getConnection等待，在等待中重试的时间间隔
- maxSize：连接池的容量
deald-lock-max-wait和dead-lock-retry-wait的设置要小心，这两个参数的意义见我的另一个日志：XAPool原理简要分析。dead-lock-retry-wait最好设置得比较短，这样不至于线程等待很长时间，dead-lock-max-wait的设置不要太长，一般是设置成比最高并发数下应用处理时间稍长一点，设置过短在大并发下会造成提交实效导致应用数据的丢失，因为超过xapool在超过等待dead-lock-max-wait之后会异常：没有可用连接分配。
sleepTime是对Connection idle检测线程PoolKeeper的检测时间间隔设置。PoolKeeper会定时监测是否存在超过lifeTime的connection然后释放掉这些connection。不过PoolKeeper在运行的时候会检查running属性，以下是它的run方法中的代码片断：
while (! running && !Thread.interrupted()) {
System.err.println("!!!!"+System.currentTimeMillis());
try {
synchronized (this) {
wait(this.sleepTime); // wait for timeout ms before attack
}
} catch (InterruptedException e) {
break;
}
this.pool.cleanUp(); // clean up the Pool and reallocate objects
}
// release the pool.
this.pool = null;
之所以把这段代码粘出来，是因为running属性默认是true，而GenericPool在启动PookKeeper的时候并没有改变这个值，因此PookKeeper永远不会运行起来。也许这是xapool的另一个bug：）
连接池的容量设置是有讲究的，一般至少等于AppServer（或者叫WEB 容器）的最大并发数。因为xapool在达到maxSize的时候，如果还有线程需要连接，会进入等待状态（通过deadLockMaxWait设置最大等待时间，deadLockRetryWait设置等待间隔），在大并发下会造成App Server容器线程池满，Server在一段时间内（deadLockMaxWait）停止响应的现象。将连接池的容量设置成大于App Server的最大并发数，可以尽可能的避免这种情况。App Server的最大并发数=App Server的线程池线程数，Tomcat默认是75，Websphere默认是50。集群环境下，集群的最大并发数=每台集群服务器的最大并发数之和