Hassan Schroeder said: > Roger Baklund wrote: > >>>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. On a related note. You should always "close" the connection before ending the jsp, not depend on the garbage collector to do it for you. In the case of a connection pool setup this will return the connection to the pool and in the case of a direct connection setup, release the connection to mysql.
William R. Mussatto, Senior Systems Engineer Ph. 909-920-9154 ext. 27 FAX. 909-608-7061 -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]