mysql – @Never事务属性非常慢
内容导读
互联网集市收集整理的这篇技术教程文章主要介绍了mysql – @Never事务属性非常慢,小编现在分享给大家,供广大互联网技能从业者学习和参考。文章包含1737字,纯文字阅读大概需要3分钟。
内容图文
![mysql – @Never事务属性非常慢](/upload/InfoBanner/zyjiaocheng/904/99bef1282c914193959ca75255736bbe.jpg)
我编写了一些基准,用于估计事务属性的不同组合如何影响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).
内容总结
以上是互联网集市为您收集整理的mysql – @Never事务属性非常慢全部内容,希望文章能够帮你解决mysql – @Never事务属性非常慢所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错,欢迎将互联网集市网站推荐给程序员好友。
内容备注
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 gblab@vip.qq.com 举报,一经查实,本站将立刻删除。
内容手机端
扫描二维码推送至手机访问。