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