为什么不建议将 @transactional 注解与 select 操作一起使用答案

【问题标题】：Why @transactional annotation is not recommend to be used with select operation为什么不建议将 @transactional 注解与 select 操作一起使用
【发布时间】：2018-10-07 09:59:52
【问题描述】：

我是春天的新手。

为什么不建议将@transactional注解与select操作一起使用？

【问题讨论】：

你的假设来源在哪里？
@Transactional 用于可以修改数据的操作，而不是用于读取操作。
@NicholasK 不正确，@Transactional 也可以用于只读操作。而且选择也是事务性的，可以根据隔离级别和数据库特定的事务处理选择不同的记录（甚至是块）。
事实上，当您的连接关闭自动提交时，最好使用@Transactional(readOnly=true) 仅选择操作，因为这会发出很多警告...

标签： java spring spring-transactions transactional

【解决方案1】：

为什么不建议将@transactional注解与select操作一起使用？

不正确，您没有提供此类推荐的证明（请提供）并且在Spring @Transactional settings 中您具有选择或只读事务支持

readOnly  boolean  Read/write vs. read-only transaction

另外，在使用连接池时，如果您在 select 语句后不回滚/提交，则会将其视为脏提交，例如参见 Hikari's brettwooldridge comment

如果 autoCommit=false 您绝对必须调用 commit() 或 rollback() 以确保正确性。

【讨论】：

【解决方案2】：

选择操作是关于阅读的，它没有任何事务性。事务性通常是指在单个原子单元中捆绑多个对 DB 的写入。如果事务失败，则回滚整个单元以及所有捆绑的写入。因此，只有事务中的所有语句都通过，事务才能成功。

选择是只读操作。对于 Select，您可以使用诸如 - Read Dirty 或 Read after Commit 等内容，但事务性不适用。

【讨论】：

这是不正确的，即使选择是在事务中执行的，如果只是为了确定更改的可见性、锁定行为和读取修改记录的隔离等。如果你是正确的，为什么@Transactional 甚至有readOnly 属性？
如果您阅读了我的全部评论，我已经以另一种方式提到过，Read Dirty 或 Read After Commits 是定义的策略，但不是事务性的。
那条评论是不正确的：这不是它的实际工作方式。