vivo TWS Air開箱體驗：真輕 臻好聽
在vivo S15系列新機的發布會上，vivo的最新款真無線藍牙耳機vivo TWS Air也一同發布，本次就這款耳機新品給大家帶來一個簡單的分享。外包裝盒上，vivo TWS Air保持了vivo自家產
事務管理在系統開發中舉足輕重，Spring提供了精妙細膩的事務管理機制，主要分為編程式事務和聲明式事務兩大架構。
關于事務的根本概念，包括事務的本質、數據庫中的事務特性以及Spring事務的ACID屬性、隔離級別、傳播規則和行為方式等，本文將不做深入探討。我也相信讀者對此有一定的了解。
筆者將以簡潔方式闡述聲明式事務和編程式事務的概念，隨后探討筆者不推崇使用聲明式事務的理由。
借助底層API，如PlatformTransactionManager、TransactionDefinition和TransactionTemplate等核心接口，開發者能夠以編程的方式精準地進行事務管理。
在編程式事務模式中，開發者需在代碼中手動管理事務的啟動、提交和回滾等操作。
偽代碼：
public void test() { TransactionDefinition definition = new DefaultTransactionDefinition(); TransactionStatus status = transactionManager.getTransaction(definition); try { // 執行事務操作 // 提交事務 transactionManager.commit(status); } catch (DataAccessException e) { // 回滾事務 transactionManager.rollback(status); throw e; }}如以上代碼，開發者可以通過API自己控制事務。
聲明式事務管理方式允許開發者在配置的指引下進行事務管理，無需直接操作底層API進行硬編碼。開發者可以通過注解或基于配置的XML來便捷地管理事務。
@Transactionalpublic void test() { // 執行事務操作 }如上使用@Transactional注解即可為test方法添加事務控制。
當然，以上代碼只是簡化的版本，實際使用事務還需要進行一些配置。這里不展開詳細說明。
這兩種事務管理方式各有優缺點，所適用的場景也各有不同。為什么有人會拒絕使用聲明式事務呢？
通過上面的例子，我們很容易看出聲明式事務的優點：它幫助我們節省大量代碼，自動處理事務啟動、提交和回滾等操作，使開發人員擺脫繁瑣的事務管理工作。
聲明式事務管理是通過AOP實現的，其本質是在目標方法執行前后進行攔截。在執行方法之前創建或加入一個事務，在方法執行結束后根據情況選擇提交或回滾事務。
這種方式不會對代碼造成侵入性，方法內只需編寫業務邏輯即可。
然而，是否聲明式事務就一定完美無缺呢？未必如此。
首先，聲明式事務存在一個限制，即其最小作用粒度應為方法級別。
換言之，若想向某段代碼塊添加事務，就需要將該代碼塊獨立出來作為一個獨立方法。
然而，正是由于這個粒度問題，我個人并不贊成過度使用聲明式事務。注意是不建議過度使用，是過度使用
首先，由于聲明式事務通常是通過注解或配置實現的，這可能導致一個問題，即開發者有可能忽略了該事務。
事務被忽略會帶來什么問題呢？
首先，如果開發者未注意到某個方法被包裹在事務中，就可能在方法內執行諸如RPC遠程調用、消息發送、緩存更新、文件寫入等操作。
我們知道，這些操作本身無法回滾，這會導致數據不一致。
相比之下，如果使用編程式事務，業務代碼將清晰表示何處啟動、提交和回滾事務。這樣，修改代碼時，開發人員將被迫考慮所添加代碼是否應該處于事務內。
有人或許會認為已經存在聲明式事務，但是開發人員未留意，這該責怪誰。
盡管如此說，我們仍希望通過一些機制或規范，減少此類問題發生的可能性。
例如，建議大家使用編程式事務而非聲明式事務。我在多年的工作中多次遇到開發者未留意聲明式事務而導致故障。
因為有時，聲明式事務確實不夠顯著。
除了事務粒度問題外，聲明式事務還存在另一主要問題，即使看似簡化了大量代碼，一旦使用不當，便很容易導致事務失效。
以下幾種情景可能導致聲明式事務失效：
我們團隊不止一次遭遇聲明式事務失效的情況。或許您也曾有此經歷，我是深受其害的一位。
由于Spring事務基于AOP實現，在編碼中，我們可能涉及多個切面，這些切面各自處理不同事務，相互影響。
在之前的一個項目中，我曾發現我們的Service層事務全部失效，一旦SQL操作失敗未能回滾。我們追查后才發現，是因為一位同事添加了一個切面，其中實施了異常統一捕獲，導致事務切面無法捕獲異常，從而無法回滾事務。
此類問題不僅一次發生，而且難以察覺。
許多人可能會辯解，畢竟問題源于自身能力不足，對事務理解還不夠透徹，因此出現誤用。
然而，我依舊堅持認為，我們確實無法期望每個人都具備高超技能，也不可能要求所有開發者都能百分之百避免錯誤。我們能做的，是盡力通過機制或規范，減少或降低此類問題的發生幾率。
實際上，若對阿里巴巴發布的Java開發手冊有過深入研讀，便會發現其中很多規約非常珍貴，有些內容可能不易理解，甚至顯得有些生硬。然而，這些規范實則由無數開發者在實戰中摸爬滾打后總結而來。其實有些東西都是實踐出真知。
關于@Transactional的用法，規約中也有提到過，只不過規約中的觀點沒有我這么鮮明。
最后，本文觀點或許不會得到所有人的認同，很多人可能會稱：Spring官方推崇無侵入的聲明式事務，你又有何資格質疑。
老實說，初入職場的那幾年，我也鐘情于聲明式事務，認為其簡潔、"優雅"。覺得那些熱衷于編程式事務的前輩多此一舉，缺乏工匠精神。
然而，隨著線上遇到幾次問題后的反思，我們發現，有時候你的代碼確實優雅無瑕。
然而，這種優雅也常伴隨一些副作用，并且前輩們也無法指責我，因為我的做法確實無可指摘...
因此，有些事情，只能在切身體會后才能領悟。
當然，本文并非要求每個人完全放棄聲明式事務，只是提議在未來使用事務時，考慮本文所提觀點，然后自行做出選擇。
本文鏈接：http://www.www897cc.com/showinfo-26-81737-0.html你有思考過@Transactional事務是真的好用嗎？
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
上一篇： 一起聊聊在Rust中使用枚舉表示狀態
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號