|
Sunday, June 3. 2012Database connection fallback with PDOFor our database connections we PDO at work and we've extended the class with PHP to offer some other convenience functionality and wrappers. One of the things I wanted to do recently is allow the constructor of the PDO class to fail-over to our backup database connection pool in the event the primary was not available. The idea was to do something along the lines of: PHP:
<?php
class DB extends PDO {
public function __construct($dsn, $login, $pass, $backup_dsn) {
try {
parent::__construct($dsn, $login, $pass);
} catch (Exception $e) {
parent::__construct($backup_dsn, $login, $pass);
}
}
}
?>
Essentially the code would call the PDO's own constructor, if it would fail, an exception would be raised, which would then be caught by the exception handler that will attempt to connect to the backup database connection pool. Unfortunately this simple solution does not work, the reason being, is that when PDO's constructor fails to connect, it destroys the object. Which means any attempts to use or access the object fail, even $this is equal to NULL, effectively making the 2nd construct call pointless. While this behaviour makes sense on most cases, in some cases such as a fallback scenario illustrated above this is an undesired behaviour. To address this limitation I've written a small patch (http://ilia.ws/patch/pdo.txt) which introduces a PDO:: ATTR_KEEP_CLASS_CONN_FAILURE configuration option that can be passed to PDO's constructor, telling it to keep the object alive after a failed attempt to connect to the database, allowing re-connection to be attempted. With this patch in place, the above code can be implemented as per example below. PHP:
<?php
class DB extends PDO {
public function __construct($dsn, $login, $pass, $backup_dsn) {
try {
parent::__construct($dsn, $login, $pass, array(PDO:: ATTR_KEEP_CLASS_CONN_FAILURE => 1));
} catch (Exception $e) {
parent::__construct($backup_dsn, $login, $pass);
}
}
}
?>
Trackbacks
Trackback specific URI for this entry
Comments
Display comments as
(Linear | Threaded)
Maarten on :
finding out if the main server is not working might be problematic. We had the experience that the connection would have a long timeout first, making our fallback completely useless in real world cases.
This was not using PDO, so it might be different, just pointing out.. Ilia Alshanetsky on :
PDO allows you to set a connection timeout for a database, via PDO::ATTR_TIMEOUT setting or via dsn for some database (like PostgreSQL).
classidocs on :
I visited various web pages but the audio feature for audio
songs present at this web page is actually excellent. total stranger on :
Hello, I enjoy reading all of your article post. I like to write a little
comment to support you. found it on :
Sweet blog! I found it while searching on Yahoo News.
Do you have any tips on how to get listed in Yahoo News? I've been trying for a while but I never seem to get there! Appreciate it agree with on :
I'm amazed, I have to admit. Rarely do I encounter a blog that's equally educative and entertaining, and without a doubt, you've hit the nail on the head. The issue is an issue that not enough men and women are speaking intelligently about. Now i'm very happy I came across this during my search for something concerning this.
A. Kootstra on :
It seems to me that fail-over of the database connection should be handled by the connection receiving application: in this case the database server. For example by using a high-available architecture design.
The connecting application should only gracefully handle the unavailable connection. Thus not requiring these complex requirements and logic to be implemented in code. |
|
|||||||||||||||||||||||||||||||||||||||||||||||||
