dynamic number of SQL sockets?

[Stefan Winter]

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