iBatis selectKey and transactions - mysql

Question

I'm using iBatis with MySQL 5 in my Java app.
I have a persistent entity class
public class Entity {
private int id;
private Stirng property;
// setters and getters are omitted
}
Inserting new entity is done as follows:
<insert id="insert" parameterClass="MyEntity">
<selectKey resultClass="int" type="post" keyProperty="id" >
select LAST_INSERT_ID() as value
</selectKey>
{CALL insert_entity(#property#)}
</insert>
Transactions are managed inside the stored procedure as follows:
CREATE DEFINER=`user`#`%` PROCEDURE `insert`(IN p_property VARCHAR(255))
BEGIN
START TRANSACTION;
INSERT INTO entities (property) VALUES (p_property);
-- Do more stuff that requires transaction: update more tables etc.
COMMIT;
END;
What I'm trying to achieve is getting newly inserted entity id back to my Java code. While working with no concurrent DB updates, the setup above will do exactly what I want. The unclear part is what happens with concurrent DB updates - i.e. what is the exact timing and context of iBatis executing selectKey statement - I'd guess it will not be executed within the same transaction that defined in stored procedure, so it is possible that id returned will not be the id of the entity I want.
The only possible solution I can think about is avoid usage of selectKey:
<insert id="insert" parameterClass="MyEntity">
{CALL insert_entity(#property#, #id,mode=OUT#)}
</insert>
Returning the last inserted id from the stored procedure:
CREATE DEFINER=`user`#`%` PROCEDURE `insert`(
IN p_property VARCHAR(255),
OUT p_id INTEGER(11),
)
BEGIN
START TRANSACTION;
INSERT INTO entities (property) VALUES (p_property);
SELECT LAST_INSERT_ID() INTO p_id;
-- Do more stuff that requires transaction: update more tables etc.
COMMIT;
END;
Is there any better solution for this problem?
Edited: MySQL documentation for LAST_INSERT_ID states:
The ID that was generated is maintained in the server on a per-connection basis. This means that the value returned by the function to a given client is the first AUTO_INCREMENT value generated for most recent statement affecting an AUTO_INCREMENT column by that client. This value cannot be affected by other clients, even if they generate AUTO_INCREMENT values of their own. This behavior ensures that each client can retrieve its own ID without concern for the activity of other clients, and without the need for locks or transactions.
So it seems like the originals solution with selectKey will work in all the cases. However, for the complex stored procedures with multiple INSERT statements the second approach is safer.

Answer 1

Firstly, I have to state the obvious: You should seriously try to avoid doing your own transaction management inside your stored procedure.
Assuming that this is your only option, I'd say that the latter solution would be my preference, as it's is clear to any developer that the id is returned from within the transaction.