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'.
Of course -- I was trying to simplify for the purpose of discussion...
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.
OK, but the "user" here is the servlet container (Tomcat), *not* the human end user.
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.
As would temporary tables, which is why I stopped using them for request-specific data :-)
Related to this, does each process in the query log match to a single active connection? Or is that connection-pool-implementation dependent?
-- Hassan Schroeder ----------------------------- [EMAIL PROTECTED] Webtuitive Design === (+1) 408-938-0567 === http://webtuitive.com
dream. code.
-- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
