Issue Type: Bug Created: 2006-06-20T00:49:26.000+0000 Last Updated: 2007-07-05T14:43:08.000+0000 Status: Resolved Fix version(s): - 0.8.0 (21/Feb/07)
Reporter: Zend Framework (zend_framework) Assignee: Bill Karwin (bkarwin) Tags: - Zend_Db
Related issues: Attachments:
In a production enviroment it's often necessary to check if a connection was established successfully before any queries are sent to the database (e.g. switching to another slave if one server is down).
Because the PDO-Connection is only created on the first real query, there should
a) be a new method called "checkConnection" which creates the PDO-Connection and throws an Exception if something fails or b) the connection should be established in the constructor (who should create the DB object if he doesn't need it)?
Posted by Zend Framework (zend_framework) on 2006-06-20T00:50:04.000+0000
05/16/06 15:02:44: Modified by gavin
Prematurely establishing a connection can greatly increase the total number of simultaneous connections on a high volume system, as each connection may last significantly longer than absolutely necessary.
Would a callback suffice for this situation, where the connection fails on the first query?
I've seen situations where alternative functionality (e.g. different action controller) was selected based on the number of existing connections per database, connection timeout statistics, availability, and even latency of databases.
Even if a failure to connect occurs deep within the logic for an action, necessitating an "abort" and redirect to a different action, usually the CPU cycles consumed are "cheap" compared to unecessarily tying up a database connection, when the database resides on a different server. 05/20/06 13:39:05: Modified by firstname.lastname@example.org
I don't agree that prematurely establishing a connection would increase the number of simultaneous connections noticeable (maybe I'm wrong, and I'm running 5 slaves and one master server for nothing, only because I'm doing it the wrong way ;-)) But at least you should let the developer decide, if he needs to connect before sending the first query?
A callback would work, but I don't think that this would be the best solution. Maybe the finest idea would be to create in-built functionality for load-balancing to different servers, including 'fallback' when one slave is not reachable. So... let me explain my 'requirements' :-) (actually I'm using my own class around Zend_DB):
a) Extending the config array, so that it's possible to define one master server and multiple slaves. b) ba) Giving an option on all query/fetch-methods to define, whether the master or one of the slaves should be connected (speak: if it's a read-only or write query) and/or bb) extracting the query automatically (SELECTs to slaves, all other to master)
I would prefer ba) instead of bb) because sometimes the mysql slaves on my production systems are not really up-to-date (because some slower queries on a mysql-slave can cause the replication process to 'hang' a couple of seconds. So when I'm working on "important" stuff like payment processing, I prefer to work on the master. Also I'm using mysql's "HANDLER" function, and maybe others use stored procedures which should be send to the slaves, too.
For my needs it would be sufficient to "round-robin" (random) the slave-queries to one of the slaves; if one slave is not reachable, the class should try to connect to one of the others.
What do you think?
Posted by Bill Karwin (bkarwin) on 2006-11-13T15:22:36.000+0000
Changing fix version to 0.8.0.
Posted by Bill Karwin (bkarwin) on 2007-02-07T21:49:43.000+0000
Resolve in revision 3287. The getConnection() method attempts to initiate a connection, or throws an exception on failure.
Have you found an issue?
See the Overview section for more details.