Spring, iBatis, MySQL - how to manage transactions?

Question

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?

Answer 1

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.

Answer 2

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.