Spring事务边界扩展
我有一系列方法调用，其中 A 调用 B，B 调用 C，C 调用 D。A 和 D 有 @Transactional 注释。但 B 和 C 没有。在这种情况下，事务边界的范围是多少？ B 和 C 到底是交易的一部分吗？
I have a chain of method calls where A calls B that calls C that calls D. A and D have @Transactional annotation. but B and C doesn't. what is the scope of transaction boundaries in this case. are B and C part of the transaction at all?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
默认情况下 A、B、C 和D 在同一事务中工作。事务的默认传播级别是 TX_REQUIRED，这意味着如果事务不存在，则启动新事务（A 启动一个，B、C、D 参与）。
D 可以通过将其传播级别设置为 TX_REQUIRES_NEW 来启动新事务（如果您的环境支持）。在这种情况下，当 D 完成时，暂停的事务将恢复。提交 D 不会影响事务 A 的结果。回滚 A 不会回滚 D（已提交），因为它们是单独的事务。
此外，许多开发人员忘记了只有公共方法可以被标记为 @Transactional，因为 Spring 使用代理来管理事务（私有/受保护的方法在“this”上调用 - 因此代理没有机会发挥其魔力）。如果您使用字节代码注入而不是代理，则这不一定成立。
如果您想了解有关事务设计模式的更多信息，我强烈建议您阅读以下电子书（免费！ - 需要注册）： http://www.infoq.com/minibooks/JTDS。这是一个非常简单的阅读。
By default A, B, C & D work in the same transaction. The default propagation level of a transaction is TX_REQUIRED meaning a new transaction is started if one does not exist (A starts one, B, C, D participates).
D could start a new transaction by setting its propagation level to TX_REQUIRES_NEW (if your environment supports it). In that scenario, when D is done the suspended transaction is resumed. Committing D does not affect the outcome of transaction A. Rollbacking A will not rollback D (already committed) as they are separate transactions.
Also, a lot of developers forgets that only public method may be marked @Transactional as Spring uses proxies to manage the transactions (private/protected methods are called on "this" - thus the proxy has no chance to do its magic). This does not necessiraly hold true if you are using byte code injection instead of proxies.
If you wish to learn more about transaction design patterns, I strongly suggest the following ebook (free! - registration required): http://www.infoq.com/minibooks/JTDS. It is a very straightforward read.
这取决于传播@Transactional 注释的 a> 参数。
默认情况下，A 中发生的所有事情都是单个事务的一部分 - 包括由它直接和间接调用的所有方法。
其他传播模式将允许 D 挂起当前事务并启动自己的事务、在嵌套事务中执行或抛出异常，因为它不打算在现有事务中使用。
That depends on the propagation parameter of the
@Transactionalannotation.Per default, everything that happens within A is part of one single transaction - that includes all methods called directly and indirectly by it.
Other propagation mode would allow D to suspend the current transaction and start its own, execute in a nested transaction, or throw an exception because it's not meant to be used within an existing transaction.
与发生的情况无关：
如果出现这个问题，您可能存在严重的设计问题。
在 95% 的情况下，事务划分应该在应用程序的入口点进行，即在内部调用所有其他代码的服务方法中。
我能想到的唯一有效的情况是，一个
@Transactional方法调用另一个方法时，内部方法具有传播REQUIRES_NEW。如果情况并非如此：请重构您的设计，以便您的代码仅通过单个@Transactional注释。Independent of what happens:
if this question even comes up, you probably have serious design problems.
in 95% of cases, Transaction demarcation should take place at the entry point of your application, that is in a service method that calls all the other code internally.
The only valid case I can think of where one
@Transactionalmethod calls another is when the inner method has propagationREQUIRES_NEW. If that is not the case: refactor your design, so that your code only passes through a single@Transactionalannotation.如果您从 @Transactional A 调用 B 和 C，它们仍将处于事务中。
查看事务传播春季文档。
If you call B and C from a @Transactional A, they will still be in a transaction.
Have a look at transaction propagation in spring docs.