[cgiapp] Lazy DBI

[Mark Fuller]

> I would be interested to know of any flaws in my logic...

I did something like that, but went further. I started out with the
goal not to connect to the DB until necessary, and ended up with a
goal not to even test if I've already connected to the DB, or if the
handle is still alive, etc. I didn't want to have all those "if
(!$dbh) { connect }" or those DBI "pings" before every operation.

I reversed the logic so that it uses my module to execute prepared
statement handles within an eval. If it fails, it disconnects,
reconnects, and tries to execute the prepared statement handle again
(up to n times). So, the idea is, I default to just processing as if
I'm always connected to the DB. I let this DB handler catch errors,
retry connections and executions, etc.

I went one step further and let it "lazy prepare" statement handles
too. If the eval'ed execution fails, my logic determines the statement
isn't prepared. It prepares it, and then does the retry.

So, I just process without getting pedantic about "have I connected to
the DB yet?" "Did I prepare a statement?" "Can I ping the DB?" I
default to expected, and let the module handle the exceptions.

I guess the use of eval for every DBI statement execution can hurt
performance more than all the pedantic testing to know what's already
been done But, I found I always had to use an eval anyway. I found
some rare conditions seemed to be possible that could cause an
execution to die. If I wanted to really be sure I caught every failure
and handled it gracefully, I had to do the eval anyway.

Mark