Patch for Connection Pooling with DBI::ProxyServer
Hi, recently there was a large thread on connection pooling. One idea was to use DBI::ProxyServer for this purpose. This may not fit all needs, but some them, at least mine :-) The idea is to use DBI's connect_cached method together with ProxyServer. As in the above mentioned thread already discussed, this doesn't works out of the box. So I hacked my way thru the sources and send two patches which should make this possible. The first one adds the 'connect_cached' configuration directive to dbiproxy's configuration file. If set to true, DBI::ProxyServer uses connect_cached, instead of connect. This alone works pretty well in single mode (of course you have to take care that a process used the database handle before, may have set some attributes. This is similar to the usage of Apache::DBI under mod_perl), but when switching to forked mode it is pretty useless, because every connection gets a new childs and therefore doesn't get any cached connection. So the second patch changes Net::Daemon to pre-fork a fixed number of childs, before doing any processing. You can set the number with the new configuration directive 'childs' (mode is ignored in this case). Because these childs never ends (unless the parent process terminates), we now can set the connect_cached configuration directive from the first patch and get the benefit from cached connections. Any comments are welcome Gerald - Gerald Richterecos electronic communication services gmbh Internetconnect * Webserver/-design/-datenbanken * Consulting Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925151 WWW:http://www.ecos.de Fax: +49 6133 925152 - ProxyServer.pm.diff Daemon.pm.diff - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Patch for Connection Pooling with DBI::ProxyServer
Hi, Gerald, to be honest, I don't understand the details of your patch. I understand that you fork off some child processes and and use connect_cached. But how do the different processes interact? How do you guarantee, that the data from one client reaches the right server process? I can only imagine, that there is still only one process serving all clients. This is probably due to an insufficient understanding of sharing file handles. Sorry, Jochen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Patch for Connection Pooling with DBI::ProxyServer
Hi Jochen, to be honest, I don't understand the details of your patch. I understand that you fork off some child processes and and use connect_cached. But how do the different processes interact? How do you guarantee, that the data from one client reaches the right server process? There is nothing more to understand, that's all what I do. There is no interaction between the childs of the server process. The client connects to one server child, does all it's database i/o and then disconnects (when it disconnects from the db handle). So all database interaction from one client occurs with one server child process and there is no need to exchange data between the childs. Of course, the next time the same client connects to the server, it normaly doesn't get the same server child, but this doesn't matter very much. You end up with that every server childs process has an open connection to the database and if a client comes to a server process which already has opened the connection to the requested database, the server childs process doesn't need to connect anymore. It's similiar as with Apache and using Apache::DBI under mod_perl. By defining the number of childs you limit the maximum number of database connections you will open. I use it in an environment where normaly Apache::DBI keeps my database connections open, but there some seldom used connections and I don't like to end up with to many open connections. On the other side I don't like to connect for every request (because Orcale connects are slow), so DBI::ProxyServer holds the connection open for me and limits the number of open connections (and therefore the need for licences and resources). Is this more clear now? Gerald P.S. Of course it would be much better to do the same with threads, but from what I know so far not all DBD drivers are thread safe and it would me require to install a second threaded Perl. Does anybody know which DBD drivers are thread safe, not by simply serializing all calls via a mutex, but in a way that let them allow multiple requests at the same time within different threads, but in the same process? - Gerald Richterecos electronic communication services gmbh Internetconnect * Webserver/-design/-datenbanken * Consulting Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925151 WWW:http://www.ecos.de Fax: +49 6133 925152 - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
