hibernate - 使用非事务性 EJB "read"方法是否是一种好的做法？

Question

这是一个非常谦虚的问题。

有一些文章指出应该始终使用数据库事务，即使对于简单的读取操作也是如此。这是一个对我来说很有意义的任意示例:http://nhprof.com/Learn/Alerts/DoNotUseImplicitTransactions Hibernate 文档本身还说:

Always use clear transaction boundaries, even for read-only operations.

好的，看起来足够清楚了。这一直是我的假设，即。由于事务在所有情况下都将在数据库级别隐式应用，因此最好始终显式声明它们。

然后我读了类似这样的其他文章:http://www.ibm.com/developerworks/java/library/j-ts1/index.html#never (注意标注)。本文的部分内容是:

Never say never

At certain times you may want to start a transaction for a database read operation for example, when isolating your read operations for consistency or setting a specific transaction isolation level for the read operation. However, these situations are rare in business applications, and unless you're faced with one, you should avoid starting a transaction for database read operations, as they are unnecessary and can lead to database deadlocks, poor performance, and poor throughput.

关于死锁和吞吐量低下的问题对我来说也很有意义。

最低层的建议相互矛盾。没关系;作为一个谦虚的应用程序开发人员，我可以在这里做出自己的决定，我认为:更喜欢前面的建议，也许看看给定的 ORM/数据库组合是否在某些性能关键的情况下在没有事务的情况下实现了更好的性能。如果我错了，请纠正我。

现在我备份到应用程序服务器和 XA 事务领域。

如果我有一个执行只读操作的 EJB 方法，那么始终将其声明为事务性的(遵循上述 Hibernate 建议的精神)是一个好的做法吗？或者将其标记为 @TransactionAttribute(TransactionAttributeType.SUPPORTS) 是否并不意味着有关金属附近的数据库事务策略的太多信息？

我的意思是，EJB (JTA) 事务发生在应用程序服务器级别。可能的情况是(我不知道)，当 Java EE 应用程序服务器与 Hibernate 交互时，Hibernate 将始终强制执行显式数据库级事务，而不管应用程序服务器级事务策略如何。因此，我在这里引用的以 Hibernate 为中心的文章可能不适用于应用程序服务器级 JTA 事务——也许将只读方法标记为 @TransactionAttribute( TransactionAttribute.SUPPORTS) 而不是 REQUIRED。

这里人们的想法是什么？欢迎所有的指点——甚至是基本信息。

Answer 1

我认为使用 TransactionAttribute.SUPPORTS 没有问题，但您必须确定您正在操作的上下文。

你真正想说的是:“我不关心脏读”。或者幻读。您返回给用户的数据不能保证处于一致状态，对于许多应用程序来说，这没关系。

实际上，我发现作为企业开发人员，我们倾向于过度使用事务。他们有大量的开销。在读入的数据不会影响后续写入操作的情况下，您的业务案例实际上可能会容忍显示一些过时的数据。

简而言之，我认为 EJB3 Tx 注释都有其用途。如果您正确理解它们的语义和您的应用程序，您就可以就哪种 Tx 模式更合适做出明智的决定。

S，
ALR