- 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。集群環境下，集群的最大并發數=每臺集群服務器的最大并發數之和