- sleepTime：PoolKeeper檢測時間間隔
- lifeTime：連接生命周期（上次訪問時間-當(dāng)前時間）
- deadLockMaxWait(：超過最大連接之后的調(diào)用getConnection的等待時間
- deadLockRetryWait：超過最大連接之后的調(diào)用getConnection等待，在等待中重試的時間間隔
- maxSize：連接池的容量
deald-lock-max-wait和dead-lock-retry-wait的設(shè)置要小心，這兩個參數(shù)的意義見我的另一個日志：XAPool原理簡要分析。dead-lock-retry-wait最好設(shè)置得比較短，這樣不至于線程等待很長時間，dead-lock-max-wait的設(shè)置不要太長，一般是設(shè)置成比最高并發(fā)數(shù)下應(yīng)用處理時間稍長一點，設(shè)置過短在大并發(fā)下會造成提交實效導(dǎo)致應(yīng)用數(shù)據(jù)的丟失，因為超過xapool在超過等待dead-lock-max-wait之后會異常：沒有可用連接分配。
sleepTime是對Connection idle檢測線程PoolKeeper的檢測時間間隔設(shè)置。PoolKeeper會定時監(jiān)測是否存在超過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屬性默認(rèn)是true，而GenericPool在啟動PookKeeper的時候并沒有改變這個值，因此PookKeeper永遠(yuǎn)不會運行起來。也許這是xapool的另一個bug：）
連接池的容量設(shè)置是有講究的，一般至少等于AppServer（或者叫WEB 容器）的最大并發(fā)數(shù)。因為xapool在達(dá)到maxSize的時候，如果還有線程需要連接，會進入等待狀態(tài)（通過deadLockMaxWait設(shè)置最大等待時間，deadLockRetryWait設(shè)置等待間隔），在大并發(fā)下會造成App Server容器線程池滿，Server在一段時間內(nèi)（deadLockMaxWait）停止響應(yīng)的現(xiàn)象。將連接池的容量設(shè)置成大于App Server的最大并發(fā)數(shù)，可以盡可能的避免這種情況。App Server的最大并發(fā)數(shù)=App Server的線程池線程數(shù)，Tomcat默認(rèn)是75，Websphere默認(rèn)是50。集群環(huán)境下，集群的最大并發(fā)數(shù)=每臺集群服務(wù)器的最大并發(fā)數(shù)之和