杂记-@Transactional使用的一点记录-平芜编程栈

一、问题记录

在设计一个简单的重命名修改方法的时候考虑使用乐观插入+异常捕获来优化代码，其中用到了@Transaction这个注解。然而这里发现了一个致命缺陷，spring事务的问题。

永远不要在@Transactional方法内部依赖try-catch来处理由数据库约束引起的RuntimeException，并期望事务能继续正常提交。

原代码如下：

@Transaction private void processFileNameDuplicate(AccountFileDO accountFileDO) { String originalFileName = accountFileDO.getFileName(); Long accountId = accountFileDO.getAccountId(); Long parentId = accountFileDO.getParentId(); // 首先尝试插入原始文件名（乐观插入） try { accountFileMapper.insert(accountFileDO); return; // 插入成功，直接返回 } catch (DataIntegrityViolationException e) { // 文件名冲突，需要重命名 } // 文件名冲突处理 String baseName, extension = ""; int dotIndex = originalFileName.lastIndexOf("."); if (dotIndex > 0 && dotIndex < originalFileName.length() - 1) { baseName = originalFileName.substring(0, dotIndex); extension = originalFileName.substring(dotIndex); } else { baseName = originalFileName; } int counter = 1; String newFileName; do { newFileName = baseName + "(" + counter + ")" + extension; counter++; accountFileDO.setFileName(newFileName); try { accountFileMapper.insert(accountFileDO); return; // 成功插入新文件名 } catch (DataIntegrityViolationException e) { // 继续循环尝试下一个文件名 } } while (true); }

分析这个乐观锁加异常捕获的设计（通过数据库的插入成功与否来判断新的命名是否可用），当第一次插入判断失败，进入给文件名加后缀继续插入判断的循环，直到插入判断成功，spring仍然保留着最初的异常DataIntegrityViolationException,最终在默认的@Transaction隔离级别下会执行回滚，数据库的那一套事务会收到spring给的ROLLBACK指令。这样就会出现一个BUG，Java 对象accountFileDO的状态不会回滚，尽管被修正了，在数据库中依然查询不到。

二、设计思路和修正思路

策略	方法	缺陷
内存全量加载	使用预查询的方法将文件名全部取到SET集合中，避免事务问题，最终加上联合唯一索引确保最终一致性;	内存瓶颈：当单个目录文件数量巨大时（如超过10万），会消耗大量内存。
目标化数据库查询	先乐观地检查原始名是否存在。如果存在，再用`LIKE`或`REGEXP`查询只捞出相关的重名文件（如`笔记(%).txt`），然后在内存中计算	1.数据库压力：`LIKE`或`REGEXP`查询可能无法完美利用索引，在千万级文件的目录下仍可能较慢。2.并发问题：依然存在“检查-操作”的竞态条件，需要数据库唯一索引来兜底。
乐观插入与异常捕获	不做任何`SELECT`检查，直接尝试`INSERT`。如果成功，万事大吉。如果失败（捕获唯一键异常），则在`catch`块中处理重命名逻辑，再次尝试`INSERT`	1.失败时最慢：异常的抛出和捕获、事务的回滚，开销很大。如果冲突频繁，性能会急剧下降。2.代码复杂性高：需要处理 Spring`@Transactional`的回滚陷阱，通常需要隔离事务，实现起来非常复杂且易错。3.设计模式争议：滥用异常来控制正常的业务流程。
架构级优化	1. 分布式锁：在执行任何数据库操作前，先通过 Redis (`SETNX`) 等中间件获取一个代表该文件名的分布式锁，确保同一时间只有一个线程能操作这个名字。2. ID与名称解耦：文件在数据库中的唯一标识是`UUID`，而用户看到的文件名只是一个可变的“别名”。唯一性约束放在`(parent_id, alias_name)`上。	1.引入新依赖：需要引入并维护 Redis 等外部系统，增加了系统复杂度。2.设计更复杂：需要从系统设计的更高层面去规划，不再是单个函数的优化。

针对于方案3，修正思路是启用一个沙箱机制，将数据库插入判断操作放到由@Transactional(propagation = Propagation.REQUIRES_NEW, noRollbackFor = DataIntegrityViolationException.class)注解的方法内部。

代码如下：

import org.springframework.beans.factory.annotation.Autowired; import org.springframework.stereotype.Component; import org.springframework.transaction.annotation.Propagation; import org.springframework.transaction.annotation.Transactional; import org.springframework.dao.DataIntegrityViolationException; @Component public class AccountFileSaver { @Autowired private AccountFileMapper accountFileMapper; /** * 在一个全新的、独立的事务中尝试插入数据。 * 这是实现策略三的关键。 * * @param accountFileDO 要插入的文件对象 * @throws DataIntegrityViolationException 如果发生唯一键冲突，则向上抛出 */ @Transactional(propagation = Propagation.REQUIRES_NEW) public void tryInsert(AccountFileDO accountFileDO) { // 这个insert操作在自己的“事务沙箱”里运行。 // 如果成功，这个小事务就自己提交了。 // 如果因为唯一键冲突失败，它会抛出异常，并且这个小事务自己回滚。 // 关键在于，它的失败不会“污染”调用它的外部主事务。 accountFileMapper.insert(accountFileDO); } }

最终调用注入该类，调用tryInsert()方法代替原始的插入。实现外置沙箱处理掉异常，不影响外部事务。

三、使用@Transaction的一些总结

Spring AOP 代理机制

@Transactional注解是通过 Spring AOP（面向切面编程）的代理机制来实现的。
当你调用一个 Bean 的方法时（比如serviceA.methodA()），你实际调用的是 Spring 为serviceA创建的代理对象。这个代理对象在调用真实方法前后，会为你加上开启事务、提交/回滚事务的逻辑。
但是，如果在一个类内部，一个方法调用同一个类的另一个方法（this.methodB()），这个调用是直接在对象内部发生的，不会经过代理。因此，methodB上的@Transactional注解就会失效。
所以，我们必须把tryInsert方法放到另一个独立的类 (AccountFileSaver) 中，然后通过注入来调用 (accountFileSaver.tryInsert())。这样才能确保每次调用都经过代理，从而让Propagation.REQUIRES_NEW生效。