Skip to content
  • Marek Szuba's avatar
    b11de370
    dbConnection.t: do not use $dbh->ping() to check if disconnected from DB · b11de370
    Marek Szuba authored
    A bugfix implemented in DBD::mysql between 4.049 and 4.050 means that
    pinging a MySQL server now implicitly reestablishes the connection if
    down for whatever reason. Moreover, it is not clear from DBI
    documentation whether ping() is supposed to check if the connection to
    the database was open before calling it or not (it says "if the database
    server is still running and the connection to it is still working",
    which may well mean the _network_ connection between the client and the
    server rather than an open _database_ connection) and the behaviour of
    specific implementations varies. For instance:
     - DBD::Oracle: according to documentation it returns "either 0,
       indicating that the connection is no longer valid, or 1 indicating
       the connection is valid", under the bonnet it calls either OCIPing()
       (if available) or OCIServerVersion(). In light of the facts both of
       these methods take a service-context handle as an argument and that
       disconnect() calls OCIServerDetach(), which quite thoroughly releases
       resources allocated to the database client, it is likely ping() will
       return 0 if disconnected;
     - DBD::Pg: according to documentation it checks "if there is a
       working connection to an active database server", the code under
       the bonnet is non-trivial but the module's test suite indicates
       ping() is supposed to return 0 after disconnect();
     - DBD::SQLite: according to documentation it checks "if the
       database connection is active", under the bonnet seems to rely on
       the "Active" flag (see below);
     - finally, DBD::mysql - documentation simply says "this can be used to
       ping the server" and under the bonnet the module explicitly attempts
       to reconnect to the database, which only did not happen due to the
       aforementioned bug.
    
    In light of the above, we now check the "Active" attribute of the
    database handle to check if we are still connected. According to DBI
    documentation, "the exact meaning of active is somewhat vague at the
    moment. For a database handle it typically means that the handle is
    connected to a database ($dbh->disconnect sets Active off)"; the latter
    is indeed the case for all four DBD modules mentioned above.
    
    This fixes dbConnection.t test failures when running with
    DBD::mysql-4.050.
    
    Note that there are still some occurrences of ping() in the test file,
    however in the remaining cases it is called as a method of
    $dbc->db_handle rather than of $dbh. These should in theory be one and
    the same but just to be extra careful, we will take care of those
    separately.
    b11de370
    dbConnection.t: do not use $dbh->ping() to check if disconnected from DB
    Marek Szuba authored
    A bugfix implemented in DBD::mysql between 4.049 and 4.050 means that
    pinging a MySQL server now implicitly reestablishes the connection if
    down for whatever reason. Moreover, it is not clear from DBI
    documentation whether ping() is supposed to check if the connection to
    the database was open before calling it or not (it says "if the database
    server is still running and the connection to it is still working",
    which may well mean the _network_ connection between the client and the
    server rather than an open _database_ connection) and the behaviour of
    specific implementations varies. For instance:
     - DBD::Oracle: according to documentation it returns "either 0,
       indicating that the connection is no longer valid, or 1 indicating
       the connection is valid", under the bonnet it calls either OCIPing()
       (if available) or OCIServerVersion(). In light of the facts both of
       these methods take a service-context handle as an argument and that
       disconnect() calls OCIServerDetach(), which quite thoroughly releases
       resources allocated to the database client, it is likely ping() will
       return 0 if disconnected;
     - DBD::Pg: according to documentation it checks "if there is a
       working connection to an active database server", the code under
       the bonnet is non-trivial but the module's test suite indicates
       ping() is supposed to return 0 after disconnect();
     - DBD::SQLite: according to documentation it checks "if the
       database connection is active", under the bonnet seems to rely on
       the "Active" flag (see below);
     - finally, DBD::mysql - documentation simply says "this can be used to
       ping the server" and under the bonnet the module explicitly attempts
       to reconnect to the database, which only did not happen due to the
       aforementioned bug.
    
    In light of the above, we now check the "Active" attribute of the
    database handle to check if we are still connected. According to DBI
    documentation, "the exact meaning of active is somewhat vague at the
    moment. For a database handle it typically means that the handle is
    connected to a database ($dbh->disconnect sets Active off)"; the latter
    is indeed the case for all four DBD modules mentioned above.
    
    This fixes dbConnection.t test failures when running with
    DBD::mysql-4.050.
    
    Note that there are still some occurrences of ping() in the test file,
    however in the remaining cases it is called as a method of
    $dbc->db_handle rather than of $dbh. These should in theory be one and
    the same but just to be extra careful, we will take care of those
    separately.
Loading