Hi,
Yes and no. I'm wary of adding yet *another* pool implementation to the server.
I'd rather just get rid of the SQL pool code entirely. Instead, it should create one SQL socket per thread, and keep re-using that in the same thread. More threads will give you more sockets. When the thread goes away, the socket can be closed, too.
Sounds interesting. There are some things to consider I guess. Threads are not bound to specific virtual servers, right? Then they may be called for multiple uses, multiple sql module instances and may thus require multiple *different* sockets to *different* servers. One idea would be to allow every thread to use one socket per sql module instance it uses. And/or, bind threads to virtual servers so that they always get to use the same sql modules, as configured in that virtual server. And someone deploying it needs to keep a firm eye on the maximum number of sockets his SQL server could get since SQL servers typically impose a max per-user, per-IP or global connection limit. So 15 threads, three SQL modules each can already get up to a max of 45 sockets in use... Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473