成人免费xxxxx在线视频软件_久久精品久久久_亚洲国产精品久久久_天天色天天色_亚洲人成一区_欧美一级欧美三级在线观看

再深一點:面試工作兩不誤,源碼級理解Spring事務

開發 架構
Spring有5種隔離級別,7種傳播行為。這是面試常問的內容,也是代碼中經常碰到的知識點。這些知識枯燥而且乏味,其中有些非常的繞。如果栽在這上面,就實在是太可惜了。

 Spring有5種隔離級別,7種傳播行為。這是面試常問的內容,也是代碼中經常碰到的知識點。這些知識枯燥而且乏味,其中有些非常的繞。如果栽在這上面,就實在是太可惜了。

 

xjjdog在一些事務的基礎上,再探討幾個容易淡忘的概念,從源碼層面找原因,加深我們的理解,問題大概包括:

  1. Spring的事務和數據庫的事務隔離是一個概念么?
  2. Spring是如何實現事務的?
  3. 事務隔離機制都有哪些?
  4. 事務傳播機制都有哪些?
  5. 查詢語句需要開事務么?
  6. private方法加事務注解有用么?

1、Spring的事務和數據庫的事務隔離是一個概念么?

先來第一個問題,Spring的事務隔離級別和數據的事務隔離級別,是一回事么?

其實,數據庫一般只有4種隔離機制,Spring抽象出一種default,根據數據設置來變動。

 

  • read uncommitted(未提交讀)
  • read committed(提交讀、不可重復讀)
  • repeatable read(可重復讀)
  • serializable(可串行化)
  • default (PlatformTransactionManager默認的隔離級別,使用的就是數據庫默認的)

這是因為,Spring只提供統一事務管理接口,具體實現都是由各數據庫自己實現(如MySQL)。Spring會在事務開始時,根據當前環境中設置的隔離級別,調整數據庫隔離級別,由此保持一致。

在DataSourceUtils文件中,代碼詳細的輸出了這個過程。

  1. // Apply specific isolation level, if any
  2. Integer previousIsolationLevel = null
  3. if (definition != null && definition.getIsolationLevel() != TransactionDefinition.ISOLATION_DEFAULT) { 
  4.     if (logger.isDebugEnabled()) { 
  5.         logger.debug("Changing isolation level of JDBC Connection [" + con + "] to " + 
  6.                 definition.getIsolationLevel()); 
  7.     } 
  8.     int currentIsolation = con.getTransactionIsolation(); 
  9.     if (currentIsolation != definition.getIsolationLevel()) { 
  10.         previousIsolationLevel = currentIsolation; 
  11.         con.setTransactionIsolation(definition.getIsolationLevel()); 
  12.     } 

結論:三種情況,如果Spring沒有指定事務隔離級別,則會采用數據庫默認的事務隔離級別;當Spring指定了事務隔離級別,則會在代碼里將事務隔離級別修改為指定值;當數據庫不支持這種隔離級別,效果則以數據庫的為準(比如采用了MyISAM引擎)。

我們會使用如下的方式進行聲明。如果不是有性能和需求問題,就不要瞎改。事務處理弄不好是會鎖表的,而鎖表在大并發的情況下是會死人的。

  1. @Transactional(isolation = Isolation.READ_UNCOMMITTED) 

2、Spring事務的7種傳播機制

只要寫代碼,代碼總會存在嵌套,或者循環,造成了事務的嵌套或者循環。那么事務在這些情況下,根據配置會有不同的反應。

 

  • REQUIRED 這是默認的。表示當前方法必須在一個具有事務的上下文中運行,如有客戶端有事務在進行,那么被調用端將在該事務中運行,否則的話重新開啟一個事務。(如果被調用端發生異常,那么調用端和被調用端事務都將回滾)
  • REQUIRE_NEW 表示當前方法必須運行在它自己的事務中。如果存在當前事務,在該方法執行期間,當前事務會被掛起
  • NESTED 如果當前方法正有一個事務在運行中,則該方法應該運行在一個嵌套事務中,被嵌套的事務可以獨立于被封裝的事務中進行提交或者回滾。如果封裝事務存在,并且外層事務拋出異常回滾,那么內層事務必須回滾,反之,內層事務并不影響外層事務。如果封裝事務不存在,則同required的一樣
  • SUPPORTS 表示當前方法不必需要具有一個事務上下文,但是如果有一個事務的話,它也可以在這個事務中運行
  • NOT_SUPPORTED 表示該方法不應該在一個事務中運行。如果有一個事務正在運行,他將在運行期被掛起,直到這個事務提交或者回滾才恢復執行
  • MANDATORY 表示當前方法必須在一個事務中運行,如果沒有事務,將拋出異常
  • NEVER 表示當方法務不應該在一個事務中運行,如果存在一個事務,則拋出異常

一般用得比較多的是REQUIRED , REQUIRES_NEW,用到其他的,你就要小心了,搞懂再用。

最怕如果這倆字了,它會將事情搞的很復雜,尤其是代碼量大的時候,你永遠不知道你寫的service會被誰用到。這就很尷尬了。

我們會采用下面的方式進行聲明。鑒于Spring的事務傳播非常的繞,如果功能滿足需求,那么就用默認的就好,否則會引起不必要的麻煩。

  1. @Transactional(propagation=Propagation.REQUIRED) 

3、事務傳播機制是怎么實現的?

事務傳播機制看似神奇,實際上是使用簡單的ThreadLocal的機制實現的。所以,如果調用的方法是在新線程調用的,事務傳播實際上是會失效的。這不同于我們以前講到的透傳,Spring并沒有做這樣的處理。

所以事務傳播機制,只有翻一遍源代碼,才能印象深刻。僅靠文字去傳播,很多東西會變得不可描述。

 

如圖,PlatformTransactionManager只有簡單的三個抽象接口,定義了包含JDBC在內的Spring所有的事務操作。

 

我們平常說的JDBC,只是占到其中一部分。

實現的方式,依然是使用AOP來實現的,具體的實現類是由TransactionAspectSupport來實現的。可以看到,代碼定義了一個叫做transactionInfoHolder的ThreadLocal變量,當用到它的時候,就能夠確保在同一個線程下,獲取的變量是一致的。

  1. /** 
  2.     * Holder to support the {@code currentTransactionStatus()} method, 
  3.     * and to support communication between different cooperating advices 
  4.     * (e.g. before and after advice) if the aspect involves more than a 
  5.     * single method (as will be the case for around advice). 
  6. */ 
  7. private static final ThreadLocal<TransactionInfo> transactionInfoHolder = 
  8.         new NamedThreadLocal<>("Current aspect-driven transaction"); 

具體的業務邏輯,是在invokeWithinTransaction中實現的。如果你繼續向下跟蹤的話,會找到AbstractPlatformTransactionManager類中的getTransaction方法。

  1. @Override 
  2. public final TransactionStatus getTransaction(@Nullable TransactionDefinition definition) 
  3.         throws TransactionException { 
  4.  
  5.  
  6.     // Use defaults if no transaction definition given. 
  7.     TransactionDefinition def = (definition != null ? definition : TransactionDefinition.withDefaults()); 
  8.  
  9.  
  10.     Object transaction = doGetTransaction(); 
  11.     boolean debugEnabled = logger.isDebugEnabled(); 
  12.  
  13.  
  14.     if (isExistingTransaction(transaction)) { 
  15.         // Existing transaction found -> check propagation behavior to find out how to behave. 
  16.         return handleExistingTransaction(def, transaction, debugEnabled); 
  17.     } 
  18.  
  19.  
  20.     // Check definition settings for new transaction
  21.     if (def.getTimeout() < TransactionDefinition.TIMEOUT_DEFAULT) { 
  22.         throw new InvalidTimeoutException("Invalid transaction timeout", def.getTimeout()); 
  23.     } 
  24.  
  25.  
  26.     // No existing transaction found -> check propagation behavior to find out how to proceed. 
  27.     if (def.getPropagationBehavior() == TransactionDefinition.PROPAGATION_MANDATORY) { 
  28.         throw new IllegalTransactionStateException( 
  29.                 "No existing transaction found for transaction marked with propagation 'mandatory'"); 
  30.     } 
  31.     else if (def.getPropagationBehavior() == TransactionDefinition.PROPAGATION_REQUIRED || 
  32.             def.getPropagationBehavior() == TransactionDefinition.PROPAGATION_REQUIRES_NEW || 
  33.             def.getPropagationBehavior() == TransactionDefinition.PROPAGATION_NESTED) { 
  34.         SuspendedResourcesHolder suspendedResources = suspend(null); 
  35.         if (debugEnabled) { 
  36.             logger.debug("Creating new transaction with name [" + def.getName() + "]: " + def); 
  37.         } 
  38.         try { 
  39.             return startTransaction(def, transaction, debugEnabled, suspendedResources); 
  40.         } 
  41.         catch (RuntimeException | Error ex) { 
  42.             resume(null, suspendedResources); 
  43.             throw ex; 
  44.         } 
  45.     } 
  46.     else { 
  47.         // Create "empty" transactionno actual transaction, but potentially synchronization. 
  48.         if (def.getIsolationLevel() != TransactionDefinition.ISOLATION_DEFAULT && logger.isWarnEnabled()) { 
  49.             logger.warn("Custom isolation level specified but no actual transaction initiated; " + 
  50.                     "isolation level will effectively be ignored: " + def); 
  51.         } 
  52.         boolean newSynchronization = (getTransactionSynchronization() == SYNCHRONIZATION_ALWAYS); 
  53.         return prepareTransactionStatus(def, nulltrue, newSynchronization, debugEnabled, null); 
  54.     } 

不用我做過多解釋了吧,一切明顯的邏輯,都在代碼里。事務就是在這里創建的。

4、查詢方法可以不開啟事務么?

事務有個readonly,控制了事務的只讀屬性,和事務是否開啟沒半毛錢關系。

在以前的一篇文章中,談到通過設置readonly屬性來控制語句的路由:”MySQL官方驅動“主從分離的神秘面紗(掃盲篇),這其中就用到了事務的其中一個屬性readonly,它最終是體現在數據庫連接層面的。

  1. connection.setReadOnly(true); 

在Spring中的使用方式如下:

  1. @Transactional(readOnly=true

值得注意的是,這個屬性設置之后,并不是每個底層的數據庫都支持。中間層的ORM或者驅動,也可能會拿這個屬性做一些文章,所以與其說這個readonly是功能性的,不如說是一種暗示。

拿MySQL來說,有兩種提交模式:

  • SET AUTOCOMMIT=0 禁止自動提交
  • SET AUTOCOMMIT=1 開啟自動提交

這都是實打實的SQL語句,所以如果開啟了事務,AUTOCOMMIT要為false。我們可以看到Spring做了以下幾個操作。

  1. con.setAutoCommit(false); 

如果是只讀事務,還不忘手動設置一下。

  1. if (isEnforceReadOnly() && definition.isReadOnly()) {    try (Statement stmt = con.createStatement()) { 
  2.         stmt.executeUpdate("SET TRANSACTION READ ONLY"); 
  3.     } 

這種操作是很昂貴的,如果不加Transaction注解,默認是不開啟事務的。單條的查詢語句也是沒有必要開啟事務的,數據庫默認的配置就能滿足需求。

但如果你一次執行多條查詢語句,例如統計查詢,報表查詢,在這種場景下,多條查詢SQL必須保證整體的讀一致性,否則,在前條SQL查詢之后,后條SQL查詢之前,數據被其他用戶改變,就會造成數據的前后不一。

也僅有在這種情況下,要開啟讀事務。

5、private方法加事務注解有用么?

@Transaction注解加在private上,并沒有什么卵用。

這倒不是事務處理的代碼去寫的特性。由于事務的這些功能,是通過AOP方式強加進去的,所以它收到動態代理的控制。

private和final修飾的方法,不會被代理。

但是,你卻可以把private方法放在帶有事務功能的public方法里。這樣,它看起來也有了事務的一些功能特性,但它并沒有。

End

互聯網中,用到的事務并不多,很多都是非常小、速度非常快的接口,對于開發人員來說,事務是個累贅。

但在一些帶有金融屬性的業務中,或者一些企業級開發應用中,事務確實一個繞不過的坎。一旦深入其中,就會發現這個知識點,露著血盆大口,等君入甕。

xjjdog從源碼層次,聊到了幾個面試常問的問題。不要覺得奇怪,有的人確實一直在拿著臟讀、幻讀這樣的名詞來面試。

而這些東西,都屬于當時看了恍然大悟,第二天就繼續懵逼的內容。

什么時候,才能務實一點呢?

作者簡介:小姐姐味道 (xjjdog),一個不允許程序員走彎路的公眾號。聚焦基礎架構和Linux。十年架構,日百億流量,與你探討高并發世界,給你不一樣的味道。我的個人微信xjjdog0,歡迎添加好友,進一步交流

責任編輯:武曉燕 來源: 小姐姐味道
相關推薦

2020-09-01 07:36:29

分布式鎖分布式進程

2009-02-10 09:33:00

DNS網絡訪問

2014-06-20 19:07:54

云存儲聯想企業網盤

2010-01-13 08:55:31

Windows 7音頻播放

2011-10-08 12:21:19

華碩臺式機

2015-04-27 13:29:24

2013-06-03 17:17:14

Android開發Android程序Android手機平板

2022-01-26 00:41:58

程序員學習型工作

2009-04-03 08:22:40

聯想楊元慶拳擊手

2015-10-29 17:58:57

安全WiFi瑞星

2016-07-07 17:29:40

企業辦公

2016-08-26 13:51:50

聯想系統搬遷服

2010-05-25 14:11:49

酷睿I3HTPC

2009-04-28 11:19:17

電腦保險PICC金山毒霸

2012-04-19 15:52:29

投影機推薦

2025-02-13 08:36:52

2014-06-23 14:31:34

信鴿企業IM

2020-08-18 11:26:57

巴菲特韭菜股票

2011-10-26 11:26:27

筆記本評測
點贊
收藏

51CTO技術棧公眾號

主站蜘蛛池模板: 午夜小视频在线播放 | 在线观看国产视频 | 中文字幕第二十页 | av片免费 | 亚洲国产精品一区二区第一页 | 精品国产乱码久久久久久丨区2区 | 成人av免费网站 | 成人在线观看免费 | 国产精品久久精品 | 91精品国产综合久久福利软件 | 狼人伊人影院 | 一区二区三区视频在线 | 欧美无乱码久久久免费午夜一区 | 拍真实国产伦偷精品 | 香蕉久久av | 日韩免费视频 | av日韩一区 | 国产成人免费视频 | 黄网站免费观看 | 国产综合久久 | 九九伦理电影 | 日本亚洲欧美 | 国产精品7777777 | 成人性生交大片 | 欧美福利精品 | 国产精品成av人在线视午夜片 | 欧美一级在线观看 | 在线中文字幕第一页 | 午夜爱爱毛片xxxx视频免费看 | 99久久精品一区二区成人 | 久久久精品一区二区三区 | www.日本国产| 亚洲精品在线视频 | 欧美精品a∨在线观看不卡 欧美日韩中文字幕在线播放 | 成人免费在线网 | 视频一区二区三区中文字幕 | 一区视频| 四虎影视| 超碰人人做 | 国产在线视频一区 | 精品国产一区二区三区久久久蜜月 |