根据 Spring javadoc@Transactional(propagation = Propagation.SUPPORTS)
支持当前事务,如果不存在则以非事务方式执行。类似于同名的 EJB 事务属性。
看来我可以只声明非事务性方法并完成它,所以我的问题是。
- 在哪些情况下需要 SUPPORTS 传播?
- Supports 传播的意义何在?
任何人都可以给出一个支持实际有用的真实世界示例/场景吗?
根据 Spring javadoc@Transactional(propagation = Propagation.SUPPORTS)
支持当前事务,如果不存在则以非事务方式执行。类似于同名的 EJB 事务属性。
看来我可以只声明非事务性方法并完成它,所以我的问题是。
任何人都可以给出一个支持实际有用的真实世界示例/场景吗?
我能想到的最简单的示例是将一些内容发送到 JMS 服务器的方法。如果您在事务的上下文中,您希望消息与事务范围耦合。但是,如果还没有一个事务正在运行,为什么还要调用事务服务器并启动一个只是为了做一个一次性的消息呢?
请记住,这些可以在 API 和实现上声明。因此,即使您的用例在将其放在那里和什么都不放在那里之间没有太大区别,它仍然为 API 作者增加了价值,以指定哪些操作能够包含在事务中,而不是可能调用的操作不参与交易的外部系统。
这当然是在 JTA 上下文中。在事务仅限于资源本地物理数据库事务的系统中,该功能实际上并没有太多实际用途。
readOnly=true
尤其是在使用 ORM 时,它与选择操作上的 Transactional 标志是一个很好的组合:
@Transactional(readOnly = true, propagation=Propagation.SUPPORTS)
public Pojo findPojo(long pojoId) throws Exception {
return em.find(Pojo.class, pojoId);
}
在这种情况下,如果还没有仅用于执行选择操作的新事务,请确保不支付创建新事务的价格。
虽然如果你已经在那个思考过程中,你甚至可以考虑一起抛弃事务方面:
public Pojo findPojo(long pojoId) throws Exception {
return em.find(Pojo.class, pojoId);
}
根据这个问题使用 Propagation.SUPPORTS 提高性能进行只读操作,您不应该使用 Propagation.SUPPORTS 设置只读事务:
尚不清楚该更改是否会真正提高性能。这有多个方面。首先是链接的文章已经过时并且存在令人难以置信的缺陷,因为它积极地简化了事情。如果您愿意,我可以详细介绍,但我暂时先不谈。这里有很多影响执行性能的因素。如果没有正在进行的事务,则 readOnly 标志不会传播到 JDBC 驱动程序(这会导致许多数据库的优化未应用),也不会在 Spring 的 JPA 资源管理代码中应用优化,例如显式关闭刷新,如果应用 - 如果您读取大量数据,可以显着提高性能。