關於事務與併發

    今天看到一個技術羣裏面聊到事務與併發的關係，發現好多開發者的理解不同，想把本身再工做中遇到的例子在這裏呈現出來，以告訴你們本身所理解的事務與併發，先簡單說下流程吧！

   咱們公司的A,B系統通訊使用的是ActiveMQ，主要是訂單狀態的通訊，以前遇到的一個問題是A系統經過一個事務修改了訂單的狀態要經過ActiveMQ通知B系統，B系統收到通知並處理後會再經過ActiveMQ告知A系統通知完畢，再這個過程當中訂單在A系統裏面有一個字段來標示訂單狀態，簡要的步驟就是：

• A系統處理一個事務後修改訂單狀態

• 經過ActiveMQ通知B系統，B系統收到通知後再經過ActiveMQ告知A系統

• A系統再啓動一個事務修改訂單狀態

• 假設訂單狀態正常由第一步驟到第三步驟的狀態變化爲pending---finish

   咱們遇到的問題是什麼呢？通過上述步驟以後發現A系統裏面的有些訂單狀態仍是處於pending，而根據日誌能夠看到A系統是收到了B系統裏面的消息的，而且能夠確認A系統裏面的兩個事務都是有執行的。

也就是說，在A系統裏面，有些訂單的第二個事務是執行在第一個事務以後的。

   後來查看了一下代碼，發現咱們的代碼實現其實是這樣的，上面過程的第二步驟發生在第一步驟的事務未執行完就通知了B系統，這就能夠解釋上面的現象了，因爲訂單和網絡傳輸的差別形成A系統事務執行順序的差別。

   解決方法：將代碼裏面通知B系統的模塊移到A系統裏面的第一個事務執行完畢以後。

   這裏面就有事務跟併發的關係了，在A系統裏面按照正常流程會啓動兩個順序不一樣的事務來修改訂單的狀態，而因爲代碼編寫的問題形成A系統裏面的第一個事務未執行完畢就執行了第二個事務。由這個問題咱們能夠引伸出不少的事務併發問題，比方說在設計一個系統的時候，當涉及到某些表裏面的狀態字段時，咱們更多須要的是一個流程化的設計，而不是狀態是隨便在哪一個環節就能夠改變的，要是真有那種需求的話，就是使用數據庫的鎖了，不過通常是不會這麼設計的，若是要我選擇的話，我以爲流程化會更加好一點。