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. 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 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. just my .02 -Leif On Tue, February 6, 2007 3:28 pm, Aaron Stone wrote: > > Hey folks, I've updated the multifoo architecture page on the wiki to > reflect some of my latest work on the subject. At this point I'm starting > to build the framework for the threaded server core. I think I've > eliminated the need for a thread pool library and for any super > complicated back and forth message passing between threads. > > http://www.dbmail.org/dokuwiki/doku.php?id=multifoo_architecture > > > Aaron > _______________________________________________ > Dbmail-dev mailing list > Dbmail-dev@dbmail.org > http://twister.fastxs.net/mailman/listinfo/dbmail-dev > > _______________________________________________ Dbmail-dev mailing list Dbmail-dev@dbmail.org http://twister.fastxs.net/mailman/listinfo/dbmail-dev
