Java事務學習一

Java事務學習一

 

最近工做中遇到了這樣一個問題，使得我不得不開啓本身計劃已久的事務學習計劃了。

 

問題是這個樣子的：

 

 

如上圖所示，咱們從external queue中讀取message，而後交給internal queue，再由internal queue更新到數據庫。

 

其中，external queue採用的是IBM MQ，而internal queue則是Tomcat內部的JMS queue。因爲兩者不在同一臺服務器上而且是不一樣類型的data source，須要一個XA transaction Manager來進行全局的分佈式事務管理；同理，internal queue和數據庫之間也須要用XA transaction Manager。

 

問題出現了。什麼問題呢？

第1、事務管理的問題。當消息從internal queue更新到數據庫時，雜亂在更新成功的狀況下，internal queue中的消息並無被移除；這致使了會有重複的message內容被更新到數據庫。

第2、JDBC connection pool的問題。當前採用的connection pool不提供如下特性：驗證該connection pool中的connection是否有效，若是無效，則移除。由此引發的問題是，當該connection pool中存在無效connection時，不會被移除，而是反覆的被client從該connection pool中取出，從而致使應用出現問題。

 

哇啦啦，終於把問題交代完啦。

 

聽說，某菲在看這個問題描述的時候，單單從問題描述中，就一條一條的揪出來十個須要學習的點（並且還木有發散）。

 

因而，我深深的認識到了學習事務的決定不能再拖下去了！因而，我又從雜亂的download文件夾中找出了那本《Java transaction design strategy》

 

因而…便有了下面的內容。

 

首先，補一下基本概念：

1. JDBC connection pool：

這個叫作JDBC connection pool的池子和全部的池子都差很少，就是存放了不少不少的JDBC connection。

 

和其餘池子的管理規定也差很少，client能夠從這個池子借走一根JDBC connection，而後用，用完了以後再還回來。

 

使用池子的好處和目的也差很少，就是在有多用戶的狀況下更加靈活有效地調到資源。

 

學術一點：

 

 

 

client會在JNDI Tree上查找data source，這個JNDI tree上的每一個data source 都會從connection pool裏面找connection，而後connection pool會讓JDBC driver建立數據庫的物理鏈接。

 

client分爲internal client和external client，分別表示這個client在server的內部或者外部。

 

關於JDBC connection pool的小故事就先講到這裏。這裏是最基本的基本知識，接下來咱們就聊一下對於這個問題的解決方案，咱們但願採用的Tomcat JDBC connection pool，固然他具有全部上述JDBC connection pool的基本特性，同時又有自身的獨特優點。

 

2. Tomcat JDBC connection pool

 

上面提到咱們決定採用Tomcat JDBC connection pool做爲解決那個JDBC connection pool沒有對無效connection作檢測的問題。

 

這是由於Tomcat提供了這種特性：能夠在從connection池子中借connection以及還connection以前，以及任什麼時候候對connection是否有效健康進行檢測，若是是不健康的，那麼就會從這個connection池子中丟出去。

 

好比Tomcat JDBC connection pool提供瞭如下幾個屬性提供可配置的connection體檢：

1） testOnBorrow：布爾值；用於配置connection池子是否會在借出去某個connection以前對其進行體檢。若是體檢不經過，池子就會把這個connection丟棄，而且試圖借另外一個connection出去。

 

那麼池子君又是怎樣對connection作體檢的呢？

湯姆凱特家的池子還提供了這樣一條屬性：

1）validationQuery: String；池子就是經過運行這樣一條SQL 語句來檢查某根connection是否爲正常的。一般會用「select 1」。

 

因此說嘛，咱們能夠用湯姆凱特家的JDBC connection pool去解決咱們的問題。

 

3. XA

問題描述中反反覆覆的出現幾個詞：XA，XA-compliance，2-phase commit，1.5-phase commit。究竟是什麼意思呀？

 

首先XA，某師父說XA就是global或者global transaction，就是這麼簡單。那麼全局事務是相對於局部事務的概念，分別對應於分佈式系統的事務管理和單機事務管理。

 

舉一個最簡單的 分佈式事務管理的例子，就是咱們但願從一條queue中讀出一個消息，而後更新到數據庫中。

 

某師父還說，XA就等同於2-phase commit

 

XA-compliance就是說某個resource是遵循XA規範的。

 

掃噶！

 

那麼什麼是2-phase commit呢？這個也挺有意思的，就放在個人第四條吧：）

 

4. 2-phase commit（兩階段提交）

兩階段提交的 意思其實很好理解，就是把整個的事務提交過程分爲兩個階段。

第一階段稱爲等待提交與投票階段：就是有一箇中央調度員，等着他所管理的分佈式事務系統中的各個同窗完成他們的任務，等待他們傳回本身各自的結果：或者提交，或者回滾。至此，第一階段完成。

 

第二階段稱爲統一提交階段：中央調度員根據他收到的投票結果，作出最初決定，是否提交或者回滾，而且把該決策告知該分佈式管理系統中的全部同窗，而後這些同窗們不管本身的執行結果是什麼，都要服從中央的調度，該提交提交，該回滾回滾。

 

好啦，先寫到這裏吧，我要回家啦，哈哈！