解读dbcp自动重连那些事---转载
http://agapple.iteye.com/blog/791943
可以后另一篇做對比：http://agapple.iteye.com/blog/772507
?
同樣的內容，不同的描述方式，不一樣的效果.
?
Hi all :
最近在做?offerdetail?優化時，替換了數據庫驅動，從?c3p0 0.9.1 -> dbcp 1.4?，?順便研究了下?dbcp?的自動重連的一套機制，也做一下分享，大家周知一下。
?
數據庫鏈接 常見的問題：
1.?數據庫意外重啟后，原先的數據庫連接池能自動廢棄老的無用的鏈接，建立新的數據庫鏈接
2.?網絡異常中斷后，原先的建立的?tcp?鏈接，應該能進行自動切換。比如網站演習中的交換機重啟會導致網絡瞬斷
3.?分布式數據庫中間件，比如?cobar?會定時的將空閑鏈接異常關閉，客戶端會出現半開的空閑鏈接。
?
大致思考解決思路：
1.??????sql?心跳檢查?(?主動式?)
2.??????拿鏈接嘗試一下，發現處理失敗丟棄鏈接，探雷的請求會失敗幾個 ?(?犧牲小我，完成大我的精神?)
3.??????設置合理的空閑鏈接的超時時間，避免半開鏈接?(?懶模式，解決半開鏈接?)
?
?
下面我們來看看，在?dbcp?中是如何實現。
sql?心跳檢查
sql validate?配置
<property name=?"testWhileIdle"?><value>?true?</value></property>
<property name=?"testOnBorrow"?><value>?false?</value></property>
<property name=?"testOnReturn"?><value>?false?</value></property>
<property name=?"validationQuery"?><value>select sysdate from dual</value></property>
<property name=?"validationQueryTimeout"?><value>1</value></property>
<property name=?"timeBetweenEvictionRunsMillis"?><value>30000</value></property>
<property name=?"numTestsPerEvictionRun"?><value>16</value></property>
參數說明
??
???dbcp?是采用了?commons-pool?做為其連接池管理，?testOnBorrow,testOnReturn, testWhileIdle?是?pool?是提供的幾種校驗機制，通過外部鉤子的方式回調?dbcp?的相關數據庫鏈接?(validationQuery)?校驗?, dbcp?相關外部鉤子類：?PoolableConnectionFactory,?繼承于?common-pool PoolableObjectFactory , dbcp?通過GenericObjectPool?這一入口，進行連接池的?borrow,return?處理。
具體參數描述：
?? 1. testOnBorrow :?顧明思義，就是在進行borrowObject進行處理時，對拿到的connection進行validateObject校驗
?? 2. testOnReturn :?顧明思義，就是在進行returnObject對返回的connection進行validateObject校驗，個人覺得對數據庫連接池的管理意義不大
?? 3. testWhileIdle :?關注的重點，GenericObjectPool中針對pool管理，起了一個?異步Evict的TimerTask定時線程進行控制?(?可通過設置參數?timeBetweenEvictionRunsMillis>0),?定時對線程池中的鏈接進行validateObject校驗，對無效的鏈接進行關閉后，會調用ensureMinIdle，適當建立鏈接保證最小的minIdle連接數。
?? 4. timeBetweenEvictionRunsMillis,?設置的Evict線程的時間，單位ms，大于0才會開啟evict檢查線程
?? 5. validateQuery?， 代表檢查的sql
?? 6. validateQueryTimeout?， 代表在執行檢查時，通過statement設置，statement.setQueryTimeout(validationQueryTimeout)
? ?7. numTestsPerEvictionRun?，代表每次檢查鏈接的數量，建議設置和maxActive一樣大，這樣每次可以有效檢查所有的鏈接.
Sql?心跳檢查幾點思考：
1.?性能問題。
目前網站的應用大部分的瓶頸還是在I/O這一塊，大部分的I/O還是在數據庫的這一層面上，每一個請求可能會調用10來次SQL查詢，如果不走事務，一個請求會重復獲取鏈接，如果每次獲取鏈接,比如在testOnBorrow都進行validateObject，性能開銷不是很能接受，可以假定一次SQL操作消毫0.5~1ms(一般走了網絡請求基本就這數)
2?．成本和收益
網站異常數據庫重啟，網絡異常斷開的頻率是非常低的，一般也就在數據庫升級，演習維護時才會進行，而且一般也是選在晚上，訪問量相對比較低的請求，而且一般會有人員值班關注，所以異步的validateObject是可以接受，但一個前提需要確保能保證在一個合理的時間段內，數據庫能完成自動重聯。
?
請求探雷
相關配置
dbcp?自身默認支持，不需要配置
原理描述
common-pools?通過borrowObject , returnObject完成連接的獲取和釋放，正常的情況是一次請求中borrow和return是一對的，有借就有還。
但在準備returnObject時，dbcp會做一件事，就是看看這個object是否已經是壞了的，如果壞了就直接丟了，就直接給丟棄了。
?
代碼層面：
１. 在dbcp中PoolingDataSource(實現DataSource接口)調用?PoolableConnection(dbcp connnection?相關的pool delegate操作)進行相應關閉時，會檢查?_conn.isClosed()?，針對DataSource如果isClosed返回為 true的則不調用returnObject，直接丟棄了鏈接。
２. _conn.isClosed()是否保險，從jdk的api描述中：?A connection is closed if the method close has been called on it or if certain fatal errors have occurred.?里面提供兩種情況，一種就是被調用了closed方法，另一種就是出現一些異常，說的比較含糊。
?
空閑鏈接檢查
相關配置
<property name="minEvictableIdleTimeMillis?"><value>18000000</value></property>
<property name="removeAbandoned"?><value>true</value></property>?
<property name="removeAbandonedTimeout?"><value>180</value></property>
參數說明
1.?minEvictableIdleTimeMillis? dbcp默認是30分，需要開啟異步線程Evict，否則不生效。原理很簡單，就是通過一個異步線程，每次檢查connnection上一次使用的時間戳，看看是否已經超過這個timeout時間設置。
2. removeAbandoned , removeAbandonedTimeout?，主要是用于在出現鏈接緊張時候，會掃描一些鏈接未超過removeAbandonedTimeout時間還未被釋放，會主動的關閉該鏈接。
適用情況
1.?我們使用的cobar后端會有定時關閉空閑鏈接的操作，默認的空閑鏈接timeout時間為1小時，和其他oracle , mysql?各不相同，所以設置好這個空閑鏈接的timeout時間還是挺重要.
?
2.?一般會是幾種情況出現需要removeAbandoned：
*?代碼未在finally釋放connection?,? 不過我們都用sqlmapClientTemplate，底層都有鏈接釋放的過程
*?遇到數據庫死鎖?。以前遇到過后端存儲過程做了鎖表操作，導致前臺集群中連接池全都被block住，后續的業務處理因為拿不到鏈接所有都處理失敗了。
?
?
聊聊?c3p0?配置
還有我們配置的c3p0所謂的自動重連的３個參數，
<prop key="acquireRetryAttempts">30</prop>
??? <prop key="acquireRetryDelay">1000</prop>
??? <prop key="breakAfterAcquireFailure">false</prop>
?
個人覺得就是一個誤導?，這幾個配置只是在從連接池獲取鏈接時，獲取失敗多嘗試幾次，因為我們從pool從獲取鏈接最多只會等待固定timeout時間。
如果要達到自動重連的效果，必須要c3p0支持請求探雷或者是sql心跳檢查功能，能自動的剔除無效的鏈接。
可見c3p0官方文檔描述：http://www.mchange.com/projects/c3p0/index.html#configuring_recovery
?
最后：
Dbcp?將是我們以后數據庫驅動選擇的趨勢，最后我們如何選擇如何自動重連，這個也得根據我們的應用場景而定。比如只讀的web系統，后臺業務系統，任務系統可能處理方式就不同。
只讀Web系統：可采取請求探雷的策略，也就失敗連接池個數的請求，失敗了頁面刷新一次就好。
后臺業務系統：一般業務都涉及數據庫的寫操作，很多數據不可重入，一次處理失敗后就只能靠手工干預處理。這時候得考慮是否需要使用sql心跳檢查，比如testOnBorrow或者testWhileIdle.
?
不同數據庫的validationQuery:
http://stackoverflow.com/questions/10684244/dbcp-validationquery-for-different-databases
There is not only one validationQuery for all databases. On each database you have to use different validationQuery.
After few hours of googling and testing I have collected this table:
Database validationQuery notes
- hsqldb?-?select 1 from INFORMATION_SCHEMA.SYSTEM_USERS
- Oracle?-?select 1 from dual
- DB2?-?select 1 from sysibm.sysdummy1
- mysql?-?select 1
- microsoft SQL Server?-?select 1?(tested on SQL-Server 9.0, 10.5 [2008])
- postgresql?-?select 1
- ingres?-?select 1
- derby?-?values 1
- H2?-?select 1
- Firebird?-?select 1 from rdb$database
I wrote about it on my blog -?validation query for various databases.
In advance there is an example of class, which return validationQuery according to JDBC driver.
Or does anybody have better solution?
轉載于:https://www.cnblogs.com/davidwang456/p/4161727.html
總結
以上是生活随笔為你收集整理的解读dbcp自动重连那些事---转载的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： spring beans源码解读之--B
- 下一篇： 阿里巴巴消息系统架构与变迁--转载