@Autowired
private DataSource dataSource;
@Override
@Transactional(rollbackFor = Exception.class,transactionManager = "secondaryTransactionManager")
public String generate(SerialNumberIdEnum serialNumberIdEnum) {
try (Connection conn = dataSource.getConnection()) {
log.info("数据库自动提交状态: {}", conn.getAutoCommit());
log.info("数据库事务隔离级别: {}", conn.getTransactionIsolation());
} catch (SQLException e) {
log.error("获取连接状态失败", e);
}
// 获取当前事务状态
TransactionStatus status = TransactionAspectSupport.currentTransactionStatus();
log.info("当前事务是否是新事务: {}", status.isNewTransaction());
log.info("当前事务是否有保存点: {}", status.hasSavepoint());
log.info("是否存在事务: {}", TransactionSynchronizationManager.isActualTransactionActive());
log.info("当前事务名称: {}", TransactionSynchronizationManager.getCurrentTransactionName());
log.info("事务隔离级别: {}", TransactionSynchronizationManager.getCurrentTransactionIsolationLevel());
}
2025-02-27 11:00:17.486 INFO [,4d18f74673dbc347,4d18f74673dbc347,true] 46940 --- [io-10009-exec-1] c.d.x.r.s.s.s.SerialNumberBaseService : 数据库自动提交状态: true
2025-02-27 11:00:17.514 INFO [,4d18f74673dbc347,4d18f74673dbc347,true] 46940 --- [io-10009-exec-1] c.d.x.r.s.s.s.SerialNumberBaseService : 数据库事务隔离级别: 2
2025-02-27 11:00:17.515 INFO [,4d18f74673dbc347,4d18f74673dbc347,true] 46940 --- [io-10009-exec-1] c.d.x.r.s.s.s.SerialNumberBaseService : 当前事务是否是新事务: true
2025-02-27 11:00:17.515 INFO [,4d18f74673dbc347,4d18f74673dbc347,true] 46940 --- [io-10009-exec-1] c.d.x.r.s.s.s.SerialNumberBaseService : 当前事务是否有保存点: false
2025-02-27 11:00:17.516 INFO [,4d18f74673dbc347,4d18f74673dbc347,true] 46940 --- [io-10009-exec-1] c.d.x.r.s.s.s.SerialNumberBaseService : 是否存在事务: true
2025-02-27 11:00:17.516 INFO [,4d18f74673dbc347,4d18f74673dbc347,true] 46940 --- [io-10009-exec-1] c.d.x.r.s.s.s.SerialNumberBaseService : 当前事务名称: com.dycjr.xiakuan.report.support.serialnumber.service.impl.SerialNumberMysqlService.generate
2025-02-27 11:00:17.516 INFO [,4d18f74673dbc347,4d18f74673dbc347,true] 46940 --- [io-10009-exec-1] c.d.x.r.s.s.s.SerialNumberBaseService : 事务隔离级别: null
Creating a new SqlSession
- 日志和代码解读
日志解读
日志记录了代码执行时的事务状态和数据库连接状态，以下是日志的详细解读：
数据库自动提交状态: true
表示当前数据库连接的自动提交模式是开启的。在自动提交模式下，每个独立的SQL语句都会自动开启并提交一个事务。这通常不是我们期望的，因为在显式事务管理中，我们希望手动控制事务的提交和回滚。
数据库事务隔离级别: 2
数据库的事务隔离级别是2，对应于Connection.TRANSACTION_READ_COMMITTED，即“读已提交”隔离级别。这意味着一个事务只能看到其他事务已经提交的数据。
当前事务是否是新事务: true
表示当前事务是一个新事务，而不是一个已存在的事务的子事务。
当前事务是否有保存点: false
表示当前事务没有设置保存点。保存点用于在事务中进行部分回滚。
是否存在事务: true
表示当前线程中存在一个活跃的事务。
当前事务名称: com.dycjr.xiakuan.report.support.serialnumber.service.impl.SerialNumberMysqlService.generate
表示当前事务的名称，通常是由Spring事务管理器生成的，用于标识事务的来源。
事务隔离级别: null
表示TransactionSynchronizationManager.getCurrentTransactionIsolationLevel()返回的事务隔离级别是null。这可能是因为事务隔离级别没有被显式设置，或者当前事务的隔离级别是默认值。
代码解读
代码中使用了Spring的@Transactional注解来声明事务，并通过TransactionAspectSupport和TransactionSynchronizationManager来获取事务状态。以下是代码的主要逻辑：
获取数据库连接并打印状态
使用dataSource.getConnection()获取数据库连接，并打印连接的自动提交状态和事务隔离级别。
获取当前事务状态
使用TransactionAspectSupport.currentTransactionStatus()获取当前事务的状态，包括是否是新事务、是否有保存点等。
通过TransactionSynchronizationManager获取事务状态
使用TransactionSynchronizationManager获取当前事务是否活跃、事务名称和事务隔离级别。
- 三种鉴定事务方式的区别
代码中使用了三种方式来鉴定事务状态，分别是：
通过Connection对象获取数据库连接状态
通过TransactionAspectSupport.currentTransactionStatus()获取事务状态
通过TransactionSynchronizationManager获取事务状态
区别分析
通过Connection对象获取数据库连接状态
作用：直接操作数据库连接，获取底层数据库的事务状态（如自动提交模式、隔离级别等）。
特点：
更接近底层，反映的是数据库连接的实际状态。
不依赖Spring事务管理器，即使没有Spring事务，也可以获取数据库连接的状态。
无法获取Spring事务的高级信息（如事务名称、是否是新事务等）。
适用场景：需要直接操作数据库连接，或者在没有Spring事务管理的情况下获取数据库状态。
通过TransactionAspectSupport.currentTransactionStatus()获取事务状态
作用：获取当前Spring事务的状态，包括是否是新事务、是否有保存点等。
特点：
提供了Spring事务的详细信息，如事务是否是新事务、是否有保存点等。
依赖于Spring事务管理器，只能在Spring事务上下文中使用。
不涉及底层数据库连接的状态。
适用场景：需要获取Spring事务的高级信息，或者在Spring事务中进行复杂的事务控制。
通过TransactionSynchronizationManager获取事务状态
作用：获取当前线程中事务的状态，如是否活跃、事务名称、隔离级别等。
特点：
提供了事务的高级信息，如事务名称、隔离级别等。
依赖于Spring事务管理器，只能在Spring事务上下文中使用。
更关注事务的上下文信息，而不是事务的具体状态（如是否是新事务）。
适用场景：需要获取事务的上下文信息，或者在事务同步管理中使用。
- 总结
Connection对象：用于获取底层数据库连接的状态，不依赖Spring事务管理器。
TransactionAspectSupport：用于获取Spring事务的具体状态，如是否是新事务、是否有保存点等。
TransactionSynchronizationManager：用于获取事务的上下文信息，如事务名称、隔离级别等。
这三种方式各有特点，适用于不同的场景。在实际开发中，可以根据需求选择合适的方式获取事务状态。
在日志中提到的“数据库事务隔离级别：2”对应的是Connection.TRANSACTION_READ_COMMITTED，即读已提交（Read Committed）隔离级别。
读已提交（Read Committed）
定义：在读已提交隔离级别下，一个事务只能读取到其他事务已经提交的数据。换句话说，一个事务不会读取到其他事务未提交的“脏数据”-。 特点：
避免了脏读（Dirty Read）问题，即不会读取到未提交的数据。
但仍然可能出现不可重复读（Non-Repeatable Read）和幻读（Phantom Read）问题。
不可重复读：在同一个事务中，两次读取同一行数据的结果可能不同，因为其他事务可能在这两次读取之间修改了数据并提交。
幻读：在同一个事务中，两次查询同一条件的数据，结果集可能不同，因为其他事务可能在这两次查询之间插入或删除了数据并提交。
适用场景：适用于对数据一致性要求不是特别严格的场景，但需要避免脏读。
其他数据库事务隔离级别
数据库事务隔离级别主要分为以下几种，从低到高依次为：
未提交读（Read Uncommitted）
隔离级别值：Connection.TRANSACTION_READ_UNCOMMITTED（0）
特点：
允许读取其他事务未提交的数据。
可能出现脏读、不可重复读和幻读问题。
适用场景：几乎不用于实际生产环境，因为数据一致性无法保证。
读已提交（Read Committed）
隔离级别值：Connection.TRANSACTION_READ_COMMITTED（2）
特点：
避免了脏读，但可能出现不可重复读和幻读。
适用场景：适用于对数据一致性要求不高，但需要避免脏读的场景。
可重复读（Repeatable Read）
隔离级别值：Connection.TRANSACTION_REPEATABLE_READ（4）
特点：
避免了脏读和不可重复读，但仍然可能出现幻读。
在这个隔离下级别，一个事务在读取某行数据后，其他事务不能修改或删除这行数据，直到当前事务完成。
适用场景：适用于需要保证数据在事务中多次读取结果一致的场景。
可串行化（Serializable）
隔离级别值：Connection.TRANSACTION_SERIALIZABLE（8）
特点：
最高隔离级别，避免了脏读、不可重复读和幻读。
事务之间完全隔离，就好像它们是串行执行的。
通常通过加锁机制实现，可能导致性能下降。
适用场景：适用于对数据一致性要求极高的场景，如金融交易系统。
总结
隔离级别
值
避免问题
可能问题
适用场景
未提交读
0
-
脏读、不可重复读、幻读
几乎不用于生产环境
读已提交
2
脏读
不可重复读、幻读
避免脏读，对一致性要求不高
可重复读
4
脏读、不可重复读
幻读
需要多次读取一致结果的场景
可串行化
8
脏读、不可重复读、幻读
-
对一致性要求极高的场景
在实际应用中，选择合适的隔离级别需要权衡数据一致性和性能。例如：
读已提交适用于大多数业务场景，因为它避免了脏读，同时性能较好。
可重复读适用于需要多次读取数据且结果必须一致的场景。
可串行化虽然最安全，但性能开销较大，通常只用于对一致性要求极高的场景。
