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?
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.
I'm very doubtful about your plan to use stored procedures with Ibatis. If you really need stored procedures then you can use Spring's JDBC-wrapping library to call stored procedures and leave Ibatis out of the loop entirely. Also you can mix and match, using Ibatis for some things and spring-jdbc for others.
You will have a lot easier time using Spring to manage the transactions declaratively. Your application should not need any transaction logic in it at all, either in java code or in stored procedures.
One of the advantages of using Spring is you can change your mind about how to group your sql calls into transactions without having to change code, you just change which methods on the service layer are transactional by editing the application context xml. Maybe you're used to the pre-Spring way where transactions are such a hassle, with hard-coded transaction logic and nasty exception handling, and that led you to figure that it's easier to do the transactions in stored procedures. Spring makes this a lot easier now.
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).