嵌套事務、掛起事務，Spring 是怎樣給事務又實現傳播特性的？
Spring 做為風靡世界的Java 開源框架，發揮著舉足輕重的作用。那你有沒有想過， Spring 內部又是怎么樣實現的事務呢?
而且 在 Spring 之中除了設置事務的「隔離級別」之外，還可以額外配置事務的「傳播特性」。你要知道，傳播特性里，有兩個家伙比較特別，一個PROPAGATION_REQUIRES_NEW ，還有一個是PROPAGATION_NESTED。你要知道，所謂的 REQUIRES_NEW，是會在方法級聯調用的時候，會開啟一個新的事務，同時掛起(suspend)當前事務;NESTED 代表的嵌套事務，則是在方法級聯調用的時候，在嵌套事務內執行。
我們應該都知道，這些傳播行為，是 Spring 獨有的，和數據庫沒有一毛錢關系。那在底層 Spring 用了什么黑魔法嗎?是怎么樣做到掛起事務的，又是怎么樣嵌套事務的呢?
咱們一起來揭秘。
毋庸置疑，數據的操作中，我們離不開事務。
銀行的轉帳操作中，我們相信如果一邊扣款，那對方一定會收到，而不竹籃打水一場空
事務在很多場景中都發揮著關鍵作用。
咱們先以 MySQL 為例，來捋一捋數據庫的事務，隔離級別。
然后再來看這些數據庫的配置，特性，在 Spring 里是怎樣做的事務對應的。
以及 Spring 所謂的傳播特性，又是如何作用到數據庫的事務的，怎樣做到掛起事務，嵌套事務。
事務
事務是什么?
它是一級原子性的SQL操作，一個獨立的工作單元。如果工作單元中的SQL語句執行成功，那會全部成功，一個失敗就會全部回滾。
與數據庫的事務同時為大眾熟知的是ACID。即數據庫的原子性(Atomicity)、一致性(Consistency)、隔離性(Isolation)和持久性(Durability)。就像應用內為了線程之間的互斥，線程安全等，需要做大量的工作，數據庫為了 ACID，也做了許多的工作。
隔離級別
SQL 的標準中定義了四種隔離級別，規定了哪些是事務之間可見的，哪些是事務內可見的。
READ UNCOMMITTED (未提交讀) --> 兩個事務間，一個的事務還沒提交，但被另一個看到了。
READ COMMITTED (提交讀) --> 兩個事務間，只有一個事務提交之后，另一個事務才能看到。
REPEATABLE READ (可重復讀)--> 一個事務執行中，多次讀到的結果是一樣的，即使其他事務做了修改，也先「看不見」
SERIALIZABLE (可串行化)--> 最高隔離級別，強制事務串行執行。
由于這些隔離級別，會造成所謂的「臟讀」、「幻讀」、「不可重復讀」等問題，所以需要根據具體的場景選擇適用的。
如何設置隔離級別
對于 MySQL 的隔離級別，可以全局的，也可以設置 Session 級別的。
官方文檔設置語法如下：
我們通過客戶端連接到 MySQL Server 的時候，可以做一些配置，通過jdbc的 URL 你也能看的出來，這樣設置的就是 Session 級別的。
參考上面的官方文檔，設置 session 隔離級別的命令是它：
- set session transaction isolation level SERIALIZABLE;
注意，MySQL 默認的隔離級別是 REPEATABLE READ，我的改過。同時，這里查詢當前隔離級別的SQL，舊版本的是SELECT @@TX_ISOLATION;,新版本的是SELECT @@Transaction_ISOLATION; 注意區分。
Spring 事務又是怎么回事
看過了數據庫的隔離級別之后，我們再來看 Spring 里的實現。
在 Spring 里，隔離級別的定義有五種，四個和數據庫的一致，另外包含一個 DEFAULT，代表不具體設置，直接使用數據庫定義的。
咱們看到數據庫的隔離級別可以設置 GLOBAL 級別的，也可以設置 SESSION 級別的，每個 SESSION 則代表的是一個連接。而在Spring 內，我們又是通過一個個獨立的「連接」來操作數據庫，完成CRUD。到這兒咱們應該就能知道，在 Spring 層面的設置，是通過 session 級別的 隔離來設置的，從而和數據庫里事務隔離級別做了對應來實現。
那傳播特性又是怎么回事呢?既然數據庫并不直接支持這樣的特性，Spring 又根據不同的傳播特性要求，來迂回實現了。
總結起來，對于級聯操作中，如果是REQUIRED_NEW這種的情況，所謂的掛起當前事務，開啟新的事務，是 Spring 又去申請了一個新的 Connection，這樣就會對應到一個新的事務上，然后將這個連接綁定到當前線程，再繼續執行;
對于嵌套事務，底層則是通過數據庫的 SAVEPOINT 來實現所謂的「子事務」
如果你熟悉代碼 DEBUG 過程中每個方法對應的 Frame，可以類比一下，如果執行失敗回滾的時候，可以指定回滾到當前事務的某個 SAVEPOINT，不需要全部回滾。
在 Spring 層面，是通過 JDBC 3.0來實現的，看下面這段代碼注釋。
- * <p>This transaction manager supports nested transactions via the JDBC 3.0
- * {@link java.sql.Savepoint} mechanism. The
- * {@link #setNestedTransactionAllowed "nestedTransactionAllowed"} flag defaults
- * to "true", since nested transactions will work without restrictions on JDBC
- * drivers that support savepoints (such as the Oracle JDBC driver).
事務掛起的部分代碼如下：
- /**
- * Suspend the given transaction. Suspends transaction synchronization first,
- * then delegates to the {@code doSuspend} template method.
- * @param transaction the current transaction object
- * (or {@code null} to just suspend active synchronizations, if any)
- * @return an object that holds suspended resources
- * (or {@code null} if neither transaction nor synchronization active)
- * @see #doSuspend
- * @see #resume
- */
- @Nullable
- protected final SuspendedResourcesHolder suspend(@Nullable Object transaction) throws TransactionException {
- if (TransactionSynchronizationManager.isSynchronizationActive()) {
- List<TransactionSynchronization> suspendedSynchronizations = doSuspendSynchronization();
- try {
- Object suspendedResources = null;
- if (transaction != null) {
- suspendedResources = doSuspend(transaction);
- }
- String name = TransactionSynchronizationManager.getCurrentTransactionName();
- TransactionSynchronizationManager.setCurrentTransactionName(null);
- boolean readOnly = TransactionSynchronizationManager.isCurrentTransactionReadOnly();
- TransactionSynchronizationManager.setCurrentTransactionReadOnly(false);
- Integer isolationLevel = TransactionSynchronizationManager.getCurrentTransactionIsolationLevel();
- TransactionSynchronizationManager.setCurrentTransactionIsolationLevel(null);
- boolean wasActive = TransactionSynchronizationManager.isActualTransactionActive();
- TransactionSynchronizationManager.setActualTransactionActive(false);
- return new SuspendedResourcesHolder(
- suspendedResources, suspendedSynchronizations, name, readOnly, isolationLevel, wasActive);
- }
- }
邏輯在 doSuspend里，繼續看
- @Override
- protected Object doSuspend(Object transaction) {
- DataSourceTransactionObject txObject = (DataSourceTransactionObject) transaction;
- txObject.setConnectionHolder(null);
- return TransactionSynchronizationManager.unbindResource(obtainDataSource());
- }
- @Override
- protected void doResume(@Nullable Object transaction, Object suspendedResources) {
- TransactionSynchronizationManager.bindResource(obtainDataSource(), suspendedResources);
- }
然后對應的bind 和 unbind 操作，是在ThreadLocal 對象里，將資源對象綁定或移出當前線程對應的 resources 來實現的。
- private static final ThreadLocal<Map<Object, Object>> resources =
- new NamedThreadLocal<>("Transactional resources");
- /**
- * Bind the given resource for the given key to the current thread.
- * @param key the key to bind the value to (usually the resource factory)
- * @param value the value to bind (usually the active resource object)
- * @throws IllegalStateException if there is already a value bound to the thread
- * @see ResourceTransactionManager#getResourceFactory()
- */
- public static void bindResource(Object key, Object value) throws IllegalStateException {
- Object actualKey = TransactionSynchronizationUtils.unwrapResourceIfNecessary(key);
- Assert.notNull(value, "Value must not be null");
- Map<Object, Object> map = resources.get();
- // set ThreadLocal Map if none found
- if (map == null) {
- map = new HashMap<>();
- resources.set(map);
- }
- Object oldValue = map.put(actualKey, value);
- // Transparently suppress a ResourceHolder that was marked as void...
- if (oldValue instanceof ResourceHolder && ((ResourceHolder) oldValue).isVoid()) {
- oldValue = null;
- }
- }
對比上面的說明和代碼，這兩個傳播特性的區別也很明了了：
NESTED 的特性，本質上還是同一個事務的不同保存點，如果涉及到外層事務回滾，則內層的也將會被回滾;
REQUIRED_NEW 的實現對應的是一個新的事務，拿到的是新的資源，所以外層事務回滾時，不影響內層事務。
本文轉載自微信公眾號「Tomcat那些事兒」，可以通過以下二維碼關注。轉載本文請聯系Tomcat那些事兒公眾號。
