in reply to Re^2: Preventing database handles from going stale
in thread Preventing database handles from going stale

Hmmm...I assume you're doing the queries through some kind of abstraction layer, rather than directly calling the DBI functions, which is causing the delay? If this is the case, you may need to modify said abstraction layer to do the "ping or reconnect" logic.

Example code of one of these queries might help.

__________
The trouble with having an open mind, of course, is that people will insist on coming along and trying to put things in it.
- Terry Pratchett

  • Comment on Re^3: Preventing database handles from going stale

Replies are listed 'Best First'.
Re^4: Preventing database handles from going stale
by dsheroh (Monsignor) on Feb 05, 2007 at 17:50 UTC
    Nope, I am using DBI directly, so the delay is very small. In practical terms, running the ping immediately before each query would probably be something over 99% effective, but it could never be 100% effective without implementing some kind of OS-level transactional capability to guarantee that Postgres doesn't get any processing time between the ping and the query. (And that's without even getting into cases where the db is running on a separate server with an independent CPU...)
[reply]
[d/l]
[select]
      If an established connection to your DMBS is timing out in a matter of seconds, then my first guess is that it's misconfigured. I don't know what the default timeout is for Postgres is, but many DBs let you keep a connection open for hours, if not days. MySQL, for example, defaults to 28800 seconds (8 hours) IIRC.

      Other than that, dirving's solution of wrapping queries and reconnecting on failures is the only thing I can think of.

      __________
      The trouble with having an open mind, of course, is that people will insist on coming along and trying to put things in it.
      - Terry Pratchett

[reply]
        It's not timing out in a matter of seconds, it just appears that DBD::Pg->ping is not sufficient as a keepalive. I'd estimate that I'm seeing a 5 minute timeout, but I haven't done any testing specifically aimed at verifying that.

        The race condition I'm talking about (assuming a 5 minute timeout) is that the ping could run 4 minutes 59.999 seconds after the last query (while everything is still fine), the connection times out at 5 minutes, and then the next query (tries to) run at 5 minutes and 0.001 seconds after the previous one. eval is indeed the only way to catch that scenario and recover from it, but an ounce of prevention and all that.

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom