Spring、iBatis、MySQL - 如何管理事务？
你好，我正在使用 spring ibatis 和 mysql 构建一个 Web 应用程序。
我将使用 mysql 存储过程，并使用 ibatis 调用它们。 我的问题是关于如何管理交易。 我应该在存储过程中管理事务还是使用 spring/ibatis 或两者一起管理？
Hello I'm building a web application with spring ibatis and mysql.
I'm going to use mysql stored procedures and I will call them with ibatis.
My question is about how to manage the transactions.
Should I manage the transactions inside the stored procedures or with spring/ibatis or with both?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我非常愉快地使用了 Ibatis 和存储过程，因此我认为这种方法没有什么不妥之处。
Ibatis 非常适合方便地将参数传递到更改数据过程中，以及适当地处理获取数据过程的结果集。
如果您的进程选择这样做，Ibatis 还可以处理多个结果集的输出。
在交易方面：这取决于情况。如果您的应用程序通常可以在自动提交模式下运行得非常愉快，但您有一些需要事务的不同过程，那么过程管理可能适合您。您可以设计您的应用程序，以便任何需要事务的事情都由单个“父”过程来协调。并不是说这是一个特别令人钦佩的模式，但它可能会在合理的范围内发挥作用。
如果这听起来不合适，那么 Spring 管理的事务绝对是从第一天开始实施的不错选择，并且该方法最有可能与您的应用程序一起优雅地成长。
最后的想法 - 请注意事务的嵌套，即如果您有应用程序/Spring事务管理，无论您在过程中放入什么事务处理，直到您从应用程序端提交这些“内部”提交都没有“正确”提交（它们可以有用途，但这超出了我在这里打算讨论的范围）。
编辑 - 自从写这篇文章以来，我了解到不同的数据库以不同的方式处理 COMMIT 的嵌套。似乎 Oracle 特别将 COMMIT 视为 COMMIT，无论嵌套如何，因此在其他应用程序管理的事务中提交的过程确实会正确提交。
Having used Ibatis and stored procs quite happily, I see nothing untoward in this approach.
Ibatis is great for conveniently passing parameters into your change-data procs, and for handling get-data procs' resultsets appropriately.
Ibatis can also handle output of multiple resultsets if your procs choose to do that.
On the transaction side: it depends. If your app can run generally quite happily in autocommit mode but you have a few distinct procs which need transactions, then proc-managed may work for you. You could design your app such that anything that needs transactions is orchestrated by a single "parent" proc. Not saying that's a particularly admirable pattern but it would likely work to a reasonable extent.
If this doesn't sound suitable, Spring-managed transactions is definitely a good choice to implement from day 1 and the approach most likely to grow gracefully with your app.
Final thought - be aware of nesting of transactions, i.e. if you have app/Spring transaction management, no matter what transaction handling you put in procs, until you COMMIT from the application side those "inner" commits aren't "properly" committed (they can have uses, but that's more than I intend to go into here).
Edit - since writing this, I've learned that different DBs handle nesting of COMMITs differently. Seems Oracle in particular treats a COMMIT as a COMMIT regardless of nesting, so procs that commit within an otherwise app-managed transaction do get properly committed.
我不知道你为什么要使用存储过程。既然你是，我不知道iBatis 给你买的是什么。
如果我正在编写这个应用程序，我要么使用 Spring 和 iBatis，要么使用 Spring 和存储过程，但不能同时使用两者。
我将使用 Spring 管理事务，确保在存储过程中不放置任何事务逻辑。
I don't know why you're using stored procedures. Since you are, I don't know what iBatis is buying you.
If I was writing this app, I'd either use Spring and iBatis or Spring and stored procedures, but not both.
I'd manage transactions using Spring, making sure to put NO transaction logic in the stored procedures.