Connections and Connection management

Connections are established by creating instances of the PDO base class.
It doesn't matter which driver you want to use; you always use the PDO
class name. The constructor accepts parameters for specifying the
database source (known as the DSN) and optionally for the username and
password (if any).

If there are any connection errors, a PDOException
object will be thrown. You may catch the exception if you want to handle
the error condition, or you may opt to leave it for an application
global exception handler that you set up via
set_exception_handler().

If your application does not catch the exception thrown from the PDO
constructor, the default action taken by the zend engine is to terminate
the script and display a back trace. This back trace will likely reveal
the full database connection details, including the username and
password. It is your responsibility to catch this exception, either
explicitly (via a catch statement) or implicitly via
set_exception_handler().

Upon successful connection to the database, an instance of the PDO class
is returned to your script. The connection remains active for the
lifetime of that PDO object. To close the connection, you need to
destroy the object by ensuring that all remaining references to it are
deleted—you do this by assigning NULL to the variable that holds the
object. If you don't do this explicitly, PHP will automatically close
the connection when your script ends.

Note:
If there are still other references to this PDO instance (such as from a
PDOStatement instance, or from other variables referencing the same PDO
instance), these have to be removed also (for instance, by assigning NULL to
the variable that references the PDOStatement).

Many web applications will benefit from making persistent connections to
database servers. Persistent connections are not closed at the end of the
script, but are cached and re-used when another script requests a
connection using the same credentials. The persistent connection cache
allows you to avoid the overhead of establishing a new connection every
time a script needs to talk to a database, resulting in a faster web
application.

If you wish to use persistent connections, you must set
PDO::ATTR_PERSISTENT in the array of driver options
passed to the PDO constructor. If setting this attribute with
PDO::setAttribute() after instantiation of the
object, the driver will not use persistent connections.

Note:

If you're using the PDO ODBC driver and your ODBC libraries support ODBC
Connection Pooling (unixODBC and Windows are two that do; there may be
more), then it's recommended that you don't use persistent PDO
connections, and instead leave the connection caching to the ODBC
Connection Pooling layer. The ODBC Connection Pool is shared with other
modules in the process; if PDO is told to cache the connection, then
that connection would never be returned to the ODBC connection pool,
resulting in additional connections being created to service those other
modules.

User Contributed Notes 9 notes

Using PHP 5.4.26, pdo_pgsql with libpg 9.2.8 (self compiled). As usual PHP never explains some critical stuff in documentation. You shouldn't expect that your connection is closed when you set $dbh = null unless all you do is just instantiating PDO class. Try following:

What teh heck you say at this point? Still same? Here is what you need to do to close that connection:

<?php$pdo = new PDO('pgsql:host=192.168.137.160;port=5432;dbname=platin', 'cappytoi', '1111');sleep(5);$stmt = $pdo->prepare('SELECT * FROM admin');$stmt->execute();$stmt->closeCursor(); // this is not even required$stmt = null; // doing this is mandatory for connection to get closed$pdo = null;sleep(60);?>

PDO is just one of a kind because it saves you to depend on 3rd party abstraction layers. But it becomes annoying to see there is no implementation of a "disconnect" method even though there is a request for it for 2 years. Developers underestimate the requirement of such a method. First of all, doing $stmt = null everywhere is annoying and what is most annoying is you cannot forcibly disconnect even when you set $pdo = null. It might get cleared on script's termination but this is not always possible because script termination may delayed due to slow client connection etc.

To avoid exposing your connection details should you fail to remember to catch any exception thrown by the PDO constructor you can use the following class to implicitly change the exception handler temporarily.

If you are using PHP 5.4 and later, you can no longer use persistent connections when you have your own database class that derives from the native PDO object. If you do, you will get segmentation faults during the PHP process shutdown.

Note that you can specify a port number with "port=####", but this port number will be ignored if the host is localhost. If you want to connect to a local port other than the default, use host=127.0.0.1 instead of localhost.

I would please advice people who talk about database port in reference with socket files to please read up about what a socket file is. TCP/IP uses ports, a socket file however is a direct pipe line to your database. So no, you should not replace localhost with local ip if you use a different port on your database server, because the socket file has nothing to do with your TCP/IP setup. And whenever possible, using the local socket file is much faster than establishing new TCP/IP connections on each request which is only meant for remote database servers.