今天看到一個技術羣裏面聊到事務與併發的關係，發現好多開發者的理解不一樣，想把自己再工作中遇到的例子在這裏呈現出來，以告訴大家自己所理解的事務與併發，先簡單說下流程吧！
我們公司的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系統裏面的第一個事務未執行完畢就執行了第二個事務。由這個問題我們可以引申出很多的事務併發問題，比方說在設計一個系統的時候，當涉及到某些表裏面的狀態字段時，我們更多需要的是一個流程化的設計，而不是狀態是隨便在哪個環節就可以改變的，要是真有那種需求的話，就是使用數據庫的鎖了，不過一般是不會這麼設計的，如果要我選擇的話，我覺得流程化會更加好一點。