* Hassan Schroeder > > In what situation is this unsafe? In general, you would not call > > LAST_INSERT_ID() without first having done an INSERT in the > > same session, and even with connection pooling you would usually > > use the same connection for all statements related to a session. > > What am I missing? > > Maybe I don't understand connection pooling, then. Isn't its purpose > to allow a client -- say, a webapp running in Tomcat -- to multiplex > requests for *multiple* end users over a single connection?
Almost... except for the 'single connection' part. It will maintain a pool of connections, thus the name 'pooling'. > If so, how would LAST_INSERT_ID() be able to guarantee that another > end user's INSERT hadn't preceded it? Or am I totally OTL? :-) A sensible connection pooling implementation would do something like this: - accept a client connection - if a free database connection is in the pool: - return it to the user - otherwise if the pool is full: - return error message to user "too many connections, retry later" - otherwise - create a new database connection - add it to the pool - return it to the user Once a user has got a connection, he keeps it for the entire session, that usually means untill the program ends or the connection is explicitly closed. There may be other ways to implement connection pooling, but I would say an implementation allowing separate statements from separate users intermingeled on the same connection was... well, at least special, if not broken. Besides LAST_INSERT_ID(), user variables would also be broken in such a system. -- Roger -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
