On Tue, Feb 6, 2007, Leif Jackson <[EMAIL PROTECTED]> said: > Aaron, > > From your wiki page: > >>On the issue of a database connection pool, I think that issue is mooted > by >this architecture. There are relatively few commands that do not > require >any database interaction, and the ones that dont are so fast to > process as >to not warrant the additional abstraction so that they wont > tie up a >database handle for their 0.05ms of processing time. > > Sorry not familar with editing the wiki so I will respond here.
That fine, I want to discuss things on the mailing list and post the general consensus ideas on the wiki. Wikis kinda suck for active discussion. > The need > for thread pools is limited but the database pool is a good thing to have > due to the fact that you will end up making a new connection when you get > a new pop3/imap connect, sql connections take some time vs requesting the No new threads get spun up on connections. That the whole point of this architecture :-) A single thread manages all incoming socket events and only when the events result in a complete command is that command placed into the work queue. > data in the response and so if you have a pool of open database > connections waiting there you remove that connect lag, which gets large > when MySQL gets busy. The thread of execution then just returns the > connection back to the pool when the request is completed and thus you > elemenate the churn of opening and closing DB connections. I'll eliminate the churn by having as long-lived a worker thread pool as possible. Some sizing up and down will take place, as it will in any system, but no churn. Aaron _______________________________________________ Dbmail-dev mailing list [email protected] http://twister.fastxs.net/mailman/listinfo/dbmail-dev
