內容：必須具備**回滾的能力。
場景：確保所有版本的**都有回滾能力，在準生產或者qa環境演練，必要時在生產環境，必要時在生產環境用它來解決客戶問題。
用法：清理**並遵循幾個簡單步驟以確保可以回滾**。
原因：如果沒有經歷過無法回滾**的痛，還繼續冒險地「修改-發布」**，那麼你可能會在某個時刻體會到這種痛苦。
要點：應用過於複雜或者**發布太頻繁所以不能回滾，這個藉口無法接受。穩健的飛行員不會在飛機不能著陸的時候起飛，明智的工程師不會發布不能僅僅回滾的**。
從任何版本回滾的成本幾乎總比你想象的低，能夠回滾的價值不可估量。大多數的回滾問題都出現在了資料庫中，這裡有一些簡單的規則：
1.資料庫結構的變更僅可以增加，必須到下一次版本的時候，才會清理明確不需要的列。
2.資料庫變更指令碼化並經過測試，不能手動操作，指令碼必須在測試環境測試過之後，並在一定的負載下測試過。
3.限制應用中的sql查詢的使用，開發人員需要糾正所有含糊不清的查詢，去除select * 查詢，為所有的update新增列名。
4.資料的語義變化，開發人員不可以改變版本中資料的定義，除非先發布的**可以處理新的語義狀態才可以。
5.上線/下線，應用應該有乙個基於外部配置的框架，該框架允許特定使用者可以訪問**路徑和功能。
在現在的公司遇到過一次這種情況，場面很誇張。
SpringBoot 事務回滾失敗
要麼全部成功，要麼全部失敗，不允許部分成功部分失敗。serviceimpl類內部方法的呼叫。addstudent 方法能夠執行，updatestudent 方法因為有錯誤會丟擲異常,但是事務回滾失敗。直接呼叫方法，實際上是通過this呼叫，也就是直接呼叫了方法，而不是通過spring上下文獲得 類，...
Hibernate事務不能回滾
今天的雨真tm大啊，嚇屎我了。工作之餘把hibernate複習了一下，乙個下午都沒有把事務搞定，然後是各種查資料，就差把hibernate官方文件再看一遍了。看到一篇文章猶如春風化雨，蜜糖潤喉一直以來都是用oracle資料庫，今天用的是mysql，未曾想到mysql這麼操蛋，還有表型別這一說，不是所...
Spring 中事務回滾失敗
原因一 在業務層捕捉異常，在業務層手工捕捉並處理了異常 try.catch 等於把異常 吃 掉了，spring自然不知道這裡有錯，更不會主動去回滾資料。推薦做法是在業務層統一丟擲異常，然後在控制層統一處理。如果需要在業務層增加try.catch 時 可以在 catch中增加transactionas...