-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Atif Ghaffar schreef:
>> Can I contact you off-list?
>
>> I think we have a misunderstanding on how we interpret persistent
>> connection.
I think onlist is much better to share information.
>> You are thinking in the terms of
>> one dbslayer -> many db replicas. (so perhaps you mean that the reqest
>> from the slayer will always go to the same replica)
>
>> I am trying the opposite.
>> many dblsayers -> one db. (the reason I want to do it , is that I want
>> to know exactly how many connections will the db handle).
The key observation is here:
conn = mysql_real_connect (hdl->conn,
hdl->src_ref->host.buf,
props->user.buf,
props->password.buf,
props->db.buf,
hdl->src_ref->port,
hdl->src_ref->unix_socket.buf,
CLIENT_MULTI_STATEMENTS |
CLIENT_MULTI_RESULTS);
mysql_real_connect() attempts to establish a connection to a MySQL
database engine running on host. mysql_real_connect() must complete
successfully before you can execute any other API functions that require
a valid MYSQL connection handle structure.
In that perspective you are right, for each request a new connection is
made. I wrote a handler that used pooling of connections, but there I
could always trust on the fact that I didn't introduce anything /new/.
We could implement such thing here, but as I explained that has serious
downsides regarding to what is stored for the connection local
transaction wise.
Stefan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEAREKAAYFAkrR970ACgkQYH1+F2Rqwn2c9gCbBub60tGmYAQWZexqYfcCgZc4
5dUAmwefFX6uj2nx0dcWryxuqnryI5ni
=UHui
-----END PGP SIGNATURE-----
_______________________________________________
Cherokee mailing list
[email protected]
http://lists.octality.com/listinfo/cherokee
