ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brandon Goodin <brandon.goo...@gmail.com>
Subject Re: execute SQL statement that are not in a map
Date Sun, 27 Mar 2005 16:23:46 GMT
The SQLMap either retrieves or receives  a connection from the
datasource. That connection remains on the thread for the life of the
SQLMap execution. The connection is only released when everything is
complete. So,  if you used the <selectKey> there should be no risk of
failure for LAST_INSERT_ID. Also, when a user calls startTransaction
in IBatis it will retrieve a connection at that time that will only be
returned when endTransaction is called. If you were to end a
transaction and then start another one... you would have problems.
This problem would apply also in the case where you did not use
ibatis' internal transaction demarkation and tried to retrieve the
last inserted id in another sql map call.

I'm not sure how Spring handles it connections inside transactions.
You would have to discuss that on their forums. I'd love to hear the
result of that question. However, everything else should function in
identical manner.

Bottom line is... <selectKey> wist LAST_INSERT_ID is safe especially
if you only using IBatis SQLMap.


On Sun, 27 Mar 2005 11:08:11 -0500, John Fereira <jaf30@cornell.edu> wrote:
> At 08:47 AM 3/27/2005 -0700, Brandon Goodin wrote:
> >I don't think you need to worry about LAST_INSERT_ID so long as you
> >have the same connection that inserted it. With IBatis this is not a
> >problem.
> >
> >"The last ID that was generated is maintained in the server on a
> >per-connection basis. This means the value the function returns to a
> >given client is the most recent AUTO_INCREMENT value generated by that
> >client. The value cannot be affected by other clients, even if they
> >generate AUTO_INCREMENT values of their own. This behavior ensures
> >that you can retrieve your own ID without concern for the activity of
> >other clients, and without the need for locks or transactions."
> The paragraph above assumes that the "client" always holds onto the same
> database connection.  In the case where a framework (i.e. Spring) is
> managing the database connections, perhaps using commons-dbcp, wouldn't it
> be possible that it would grab a connection from the pool, execute the
> insert, then release it back to the pool?
> John Fereira
> jaf30@cornell.edu
> Ithaca, NY

View raw message