Refine the way we detect loss of the database connection.

Refine the way we detect loss of the database connection.

This is a terrible, horrible, no good, very bad kludge.

We do an innocuous SELECT 1.  If this query succeeds, then we know that the
connection is still good.  If it fails, well...

Sometimes the SELECT 1 query fails, not because the database connection is dead,
but because (due to a previous error) the database is ignoring all commands,
even innocuous SELECTs, until the current transaction is rolled back.  The only
known way to detect this condition via the dbi library is by looking at the error
message returned by dbi_conn_error().  This approach will break if the language
or wording of the message ever changes.

Note: the dbi_conn_ping function purports to determine whether the database
connection is live.  At this writing, it follows the same approach as described
above: try a SELECT 1 and see if it works.  Consequently it presumably suffers
from the same shortcoming: it may erroneously report a dead connection when the
database is in fact just ignoring commands due to a previous error.  In addition,
if it determines (rightly or wrongly) that the connection is dead, it silently
tries to reconnect; if the reconnect is succesful, the function reports that the
connection is still alive, as if nothing had happened.  If you were in the middle
of a transaction at the time, you wouldn't know that it got rolled back.

M    Open-ILS/src/c-apps/oils_sql.c

git-svn-id: svn://svn.open-ils.org/ILS/trunk@17118 dcc99617-32d9-48b4-a31d-7c20da2025e4