mysql – @Never事务属性非常慢

2023年7月6日 194次阅读

我编写了一些基准,用于估计事务属性的不同组合如何影响
Java EE程序的性能.基准测试使用带有’X’注释的方法调用带有’Y’注释的方法.我的基准交易涵盖了银行转账的情况：

@Required            @RequiresNew
theCallerMethod() -> updateAccount(Account acc)
                     @RequiresNew
                  -> updateOwner(Company c)
                     @RequiresNew
                  -> addLogEntry(Transfer t)

因此,在callerMethod事务的上下文中,容器必须暂停调用者的事务,启动新事务,更新帐户,提交,切换到调用者,暂停,启动新事务,更新公司,提交,返回调用者的,暂停,启动另一个,添加日志条目,提交,并返回到最终提交调用者的事务的调用方法.

当我发现最慢的呼叫来自@Not-annotated caller方法时,我感到非常惊讶：为@Required执行上述1000个呼叫案例 – > @Required场景耗时5,71秒,@ Required – > @RequiresNew 6,35秒,但是9,05秒.为@Never – > @Not_Supported和8,95秒.为@Never – > @Supports.

@ Never-contexts可以执行这么久吗？我的意思是我们甚至没有暂停和恢复的交易.也许有一些我错过的关于@Never交易属性的一般知识？

我使用Java EE 6,GlassFish 3,MySQL 5.1.69 InnoDB.

提前致谢.

最佳答案

I mean we even do not have a transaction to suspend and resume.

我不会那么肯定.这就是ejb3.1 specification所说的：

13.6.5 Handling of Methods that Run with “an unspecified transaction context”

The EJB specification does not prescribe how the container should manage the execution of a method with an unspecified transaction context the transaction semantics are left to the container implementation.
Some techniques for how the container may choose to implement the execution of a method with
an unspecified transaction context are as follows (the list is not inclusive of all possible strategies):

(以及其他可能性)

The container may treat each call of an instance to a resource manager as a single transaction
(e.g. the container may set the auto-commit option on a JDBC connection).

点赞