Java 事务 API 和 .NET System.Transactions
我正在分析 JTA（Java Transactions API）和 .NET 对应的 System.Transactions 之间的不同行为：两者之间的方法有很大不同。 事实上，Java 版本的 Transactions 似乎更像是一个规范，让开发人员有义务实现 Transactions、TransactionManager 和其他定义的接口。 .NET 有一个更具体的实现，它不允许开发人员定义自己的 Transaction 对象，但提供接口来处理事务生命周期内管理的资源（而 Java 为相同的事务提供了一些 XTA* 接口）目的）
我想知道是否有人有机会将一些使用 JTA 的 Java 代码移植到 .NET，以及他/她注意到了哪些主要区别。
此外，任何人都可以向我澄清
TransactionManager.setRollbackOnly针对TransactionManager.rollback（在 JTA 中）的行为吗？ .NET 版本只有更具命令性的Transaction.Rollback方法。
I'm analyzing the different behaviors between the JTA (Java Transactions API) and the .NET counterpart System.Transactions: the approach is quite different between the two of them.
In fact, Java's version of Transactions seems more a specification, leaving to developers the obligation to implement either the Transactions, TransactionManager and other interfaces defined.
.NET has a more concrete implementation, which doesn't allow developers to define their own Transaction object, but providing interfaces to handle resources managed during the transactions's lifetime (while Java provides some XTA* interfaces for the same purpose)
I'm wondering if any out there has ever had the occasion to port some Java code making use of JTA to .NET and which main differences has he/she noticed.
Furthermore, could anyone clarify me the behavior of
TransactionManager.setRollbackOnlyagainstTransactionManager.rollback(in JTA)? .NET version has just theTransaction.Rollbackmethod which is more imperative.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
rollback() 向底层资源发送实际的回滚命令。 setRollbackOnly() 在当前事务上放置一个标记，在决定是否提交或回滚时读取该标记。 一旦 setRollbackOnly() 被调用，唯一可能的结果是回滚，但在调用 setRollbackOnly() 时实际上并没有进行回滚调用。
这就是这两种方法背后的想法。 我不确定不同的实现在多大程度上做出了这种区分，即使 setRollbackOnly() 在调用时实际上会进行回滚，它也不会产生任何实际差异。
rollback() sends an actual rollback command to the underlying resources. setRollbackOnly() puts a marker on the current transaction which is read when it's time to decide whether to commit or rollback. Once setRollbackOnly() has been called the only possible outcome is rollback but the rollback call is not actually made when setRollbackOnly() is being called.
That's the idea behind both methods. I'm not sure in how far different implementations make this distinction, and even if setRollbackOnly() would actually do a rollback when called it wouldn't make any practical difference.