【Spring 篇】基于注解的Spring事务控制详解-编程知识

在这里插入图片描述

嗨，亲爱的读者朋友们！欢迎来到这篇关于基于注解的Spring事务控制的博客。如果你曾为事务处理而头痛，那么这里将为你揭开事务的神秘面纱。我们将一步步深入探讨Spring事务的世界，用简单易懂的语言、充满情感色彩的文字，带你领略事务的奇妙之旅。

前言：什么是事务？

在我们踏入事务控制的舞台之前，让我们先来了解一下什么是事务。简而言之，事务是一系列操作，要么全部成功执行，要么全部失败回滚。这就好比你在玩电子游戏，要么通关，要么回到起点重新来过。在软件开发中，事务确保了数据的完整性和一致性，是我们保持代码健壮性的重要手段。

Spring事务管理初探

Spring框架为我们提供了一套强大而灵活的事务管理机制。而其中基于注解的事务控制，则是一种让我们事务处理变得轻松愉快的方式。不再需要繁琐的事务管理代码，一切都可以通过简单的注解来搞定。

让我们来看一个简单的例子，假设我们有一个银行服务类：

@Service
public class BankService {@Autowiredprivate AccountRepository accountRepository;@Transactionalpublic void transferMoney(String fromAccount, String toAccount, double amount) {// 从fromAccount扣除金额Account from = accountRepository.findByAccountNumber(fromAccount);from.setBalance(from.getBalance() - amount);accountRepository.save(from);// 向toAccount添加金额Account to = accountRepository.findByAccountNumber(toAccount);to.setBalance(to.getBalance() + amount);accountRepository.save(to);}
}

在这个例子中，通过在 transferMoney 方法上加上 @Transactional 注解，我们告诉Spring，这是一个事务性的方法。如果在方法执行期间发生异常，整个方法的操作将被回滚，保持数据的一致性。是不是感觉事务处理变得异常简单？

事务的传播行为：如何舞动事务的芭蕾

咱们来聊聊事务的传播行为。简而言之，传播行为定义了事务方法之间的关系。举个例子，假设我们有两个服务方法 A 和 B，A 调用了 B，那么事务传播行为就是规定了A和B之间的事务关系。

在Spring中，有几种常见的传播行为，比如 REQUIRED、REQUIRES_NEW 和 NESTED。让我们用一个小故事来解释这些概念。

小故事：Alice和Bob的银行冒险

有一天，Alice和Bob决定一同前往银行冒险。他们分别代表了两个服务方法 A 和 B，银行冒险就是一个大事务。让我们看看不同传播行为下的故事发展。

1. REQUIRED - 要共舞一场

Alice（方法A）和Bob（方法B）一起进入银行，决定共同完成这次冒险。如果Alice和Bob中任何一个遇到了困难（异常），整个冒险就失败，两人重新回到银行门口。这就是 REQUIRED 传播行为，他们共舞一场，遇到异常就一同失败。

@Transactional(propagation = Propagation.REQUIRED)
public void adventureWithBank() {aliceService.doSomething(); // AlicebobService.doSomethingElse(); // Bob
}

2. REQUIRES_NEW - 各自为政

Alice和Bob决定各自为政，独立进行银行冒险。无论其中一人失败，另一人都可以继续。这就是 REQUIRES_NEW 传播行为，各自为政，不受对方的事务影响。

@Transactional(propagation = Propagation.REQUIRES_NEW)
public void aliceAdventures() {aliceService.doSomething(); // Alice
}@Transactional(propagation = Propagation.REQUIRES_NEW)
public void bobAdventures() {bobService.doSomethingElse(); // Bob
}

3. NESTED - 嵌套情感

Alice和Bob选择进行嵌套冒险，就像一个人在另一个人的故事里。如果Bob的冒险失败，他可以独立回到银行门口；但如果Alice的冒险失败，整个故事将重新开始。这就是 NESTED 传播行为，嵌套在对方的事务中。

@Transactional(propagation = Propagation.NESTED)
public void aliceAdventures() {aliceService.doSomething(); // Alice
}@Transactional(propagation = Propagation.NESTED)
public void bobAdventures() {bobService.doSomethingElse(); // Bob
}

这些故事或许显得幼稚，但通过这种方式，你可以轻松理解不同传播行为的含义。

隔离级别：在不同舞台上的表演

事务的隔离级别是事务管理中另一个关键概念。隔离级别定义了多个事务之间的可见性和影响关系。Spring支持的隔离级别有 DEFAULT、READ_UNCOMMITTED、READ_COMMITTED、REPEATABLE_READ 和 SERIALIZABLE。

我们来看一个简单的例子，通过不同的隔离级别来理解事务的表演。

小故事：隔离级别的舞台

在这个故事中，我们有两位演员，Alice和Bob，代表两个事务。银行就是事务的舞台，而不同的隔离级别就是这场表演的不同舞台设置。

1. READ_UNCOMMITTED - 公开彩排

Alice和Bob在银行里进行公开彩排，他们可以随意看到对方的动作，即使对方的动作还没有提交。这就是 READ_UNCOMMITTED 隔离级别，即一个事务可以看到另一个事务未提交的数据。

@Transactional(isolation = Isolation.READ_UNCOMMITTED)
public void alicePerformance() {aliceService.doSomething(); // Alice
}@Transactional(isolation = Isolation.READ_UNCOMMITTED)
public void bobPerformance() {bobService.doSomethingElse(); // Bob
}

2. READ_COMMITTED - 隐蔽彩排

Alice和Bob进行了隐蔽的彩排，只有当对方的动作被提交后，才能看到。这就是 READ_COMMITTED 隔离级别，即一个事务只能看到另一个事务已经提交的数据。

@Transactional(isolation = Isolation.READ_COMMITTED)
public void alicePerformance() {aliceService.doSomething(); // Alice
}@Transactional(isolation = Isolation.READ_COMMITTED)
public void bobPerformance() {bobService.doSomethingElse(); // Bob
}

3. SERIALIZABLE - 隔离彩排

Alice和Bob决定进行严格的隔离彩排，即一个事务完全看不到另一个事务的表演。这就是 SERIALIZABLE 隔离级别，即一个事务执行时，其他事务无法对相同的数据进行更新。

@Transactional(isolation = Isolation.SERIALIZABLE)
public void alicePerformance() {aliceService.doSomething(); // Alice
}@Transactional(isolation = Isolation.SERIALIZABLE)
public void bobPerformance() {bobService.doSomethingElse(); // Bob
}

通过这个小故事，相信你对隔离级别有了更加生动的理解。

超时设置：等待表演的结束

有时候，我们可能希望限制事务的执行时间，以防止某个事务长时间占用资源。@Transactional 注解允许我们设置事务的超时时间，单位是秒。这就像是告诉演员们，你们的表演时间有限，不能一直霸占舞台。

@Transactional(timeout = 60)
public void alicePerformance() {aliceService.doSomething(); // Alice
}

在这个例子中，我们将 timeout 设置为60秒，表示这个事务的表演时间不得超过60秒。如果时间到了，不管表演是否结束，都要结束这场表演。

回滚控制：遇到意外，退场重演

在事务处理中，异常是一个无法避免的问题。Spring框架提供了 @Rollback 注解，用于控制事务是否回滚。默认情况下，Spring事务将在遇到运行时异常时回滚，但我们也可以通过 @Rollback 注解来手动控制回滚。

@Transactional
@Rollback(false)
public void alicePerformance() {aliceService.doSomething(); // Alice
}

在这个例子中，通过 @Rollback(false) 明确告诉Spring，即使在方法中抛出异常，也不要回滚事务。这种情况可能在我们需要记录异常情况但仍然希望保留部分已执行操作时有用。

读写操作的组合：舞台上的交响乐

在数据库事务中，读写操作的组合也是需要考虑的因素。Spring提供了 @Transactional 注解的 readOnly 属性，用于指定事务是否只读。

@Transactional(readOnly = true)
public List<Account> getAllAccounts() {return accountRepository.findAll();
}

在上述例子中，我们标注了 @Transactional(readOnly = true)，表示这个事务只包含读操作，不包含写操作。这有助于提高数据库的性能，因为只读事务通常可以避免获得数据库写锁。

结语：跟着音乐的节奏，轻松驾驭事务的舞台

通过这篇博客，我们深入浅出地探讨了基于注解的Spring事务控制。从事务的概念开始，逐步介绍了 @Transactional 注解、事务的传播行为、隔离级别、超时设置、回滚控制、以及一些常见的使用场景。通过生动的小故事和实际的代码示例，相信你对Spring事务管理有了更加深刻的理解。

在这个舞台上，你不再是被事务搞得头痛的观众，而是优雅地跟着音乐的节奏，轻松驾驭着事务的舞台。希望这篇博客对于初学者来说是一次愉快的学习之旅，让你能够在事务的世界里游刃有余。如果你有任何疑问或者想要分享自己的经验，不妨在评论区留下你的足迹。让我们一起共同探索事务控制的奥秘，愉快地编写出高质量的、可靠的代码。感谢你的阅读，希望你在事务的舞台上能够畅快淋漓地表演！🎭💃

作者信息

作者：繁依Fanyi
CSDN： https://techfanyi.blog.csdn.net
掘金：https://juejin.cn/user/4154386571867191