何時以及為何應調整 @Transactional 中的預設隔離和傳播參數？

@Transactional 中的隔離和傳播參數

在Spring 的@Transactional 註解中，兩個關鍵參數定義了資料庫事務的行為：隔離和傳播。本文探討了何時以及為何應考慮調整其預設值。

傳播

傳播定義事務如何相互關聯。常見選項包括：

• REQUIRED: 在現有交易中執行程式碼，如果不存在則建立新交易。
• REQUIRES_NEW: 始終建立新交易，暫停任何現有交易。

預設值： 必需

隔離

隔離性定義了事務之間的資料契約。它透過指定其他事務所所做的資料更改的可見性等級來防止某些資料不一致。關鍵隔離等級為：

• READ_UNCOMMITTED: 無髒讀取保護。
• SERIALIZABLE: 最強隔離，確保無資料衝突。

默認值： 因數據庫而異（例如，MariaDB 的REPEATABLE_READ）

真實示例

考慮髒讀的問題，其中一個事務可以讀取另一個事務所所做的未提交的更改。

                                       Thread 1          Thread 2
                                               |              |
                                             Write(x)           |
                                               |              |
                                               |             Read(x)
                                               |              |
                                             Rollback           |
                                                 |             |
                                                   Value (x) is now dirty (incorrect)

在這種情況下，為了防止髒讀，您可以將隔離等級設定為 READ_COMMITTED 並將傳播等級設為 REQUIRED。這種組合確保事務只讀取其他事務已提交的資料。

自訂事務

在以下範例中，provideService方法始終在新事務中運行，確保其他並發任務所做的任何更改不會幹擾其執行：

<code class="java">@Transactional(propagation=Propagation.REQUIRES_NEW)
public void provideService() {
    repo1.retrieveFoo();
    repo2.retrieveFoo();
}</code>

測試事務行為

驗證不同傳播層級的行為，可以使用Java 檢定：

<code class="java">@Test
public void testProvideService() {
    TransactionStatus status = transactionManager.getTransaction(new DefaultTransactionDefinition());
    fooService.provideService();
    transactionManager.rollback(status);
    // Assert repository values are unchanged ...
}</code>

使用REQUIRES_NEW，fooService.provideService() 運作後不會回滾在單獨的交易中。使用REQUIRED，一切都會回滾。

以上是何時以及為何應調整 @Transactional 中的預設隔離和傳播參數？的詳細內容。更多資訊請關注PHP中文網其他相關文章！