Perrin Harkins <[EMAIL PROTECTED]> wrote:
> > And here's some more conjecture: What if the ping just times out
> > because the server is really, really busy?
> DBI will replace it, removing all references to the one that failed to
> ping, and it will go out of scope and get DESTROY'ed.
And what if you don't want to reconnect? The possibly still
connected, possibly not handle is still left around in {CachedKids}.
> When is this? DBI checks the handle when you call connect_cached, and
> if it fails to ping, the old one is replaced in the cache and sent off
> to garbage collection. If it isn't getting garbage-collected, that
> probably means you have it in global or closure somewhere.
And what if the connect fails?
(Sorry to keep bombarding you with conjecture... I'd just rather
hear "this is bulletproof or can be bulletproofed" than "this is expected to
screw up"...)
> > $dbh->transaction(sub {
> > ...
> > return $do_i_want_to_commit ? 1 : 0;
> > });
> >
> > especially now that I can nest them arbitrarily deep.
>
> If you wrap those in an eval and never do anything outside of one, it
> should work. I personally avoid doing things in sub refs because it
> caused so many problems for me when using Error's try/catch syntax.
That's what the 'transaction' method does; the code is run inside an
eval; if the sub ref returns true, it's committed, if it returns false or
raises an exception, it's rolled back.
> Well, the hack may work for you, and that may be all that matters in
> your case, but I don't think it's right to make other people think they
> need to use that instead of Apache::DBI or connect_cached.
I didn't!!! Tim told me to save the world!!! :)
- Tyler
