Comment 3 for bug 1056838

A fix to Cxn.pm resulted from using it in pt-deadlock-logger: when the parent exists after --daemonize, it disconnected the dbh in its DESTROY(). So the same dbh in the child's copy of the Cxn was dead on arrival, so to speak. The affects only pt-kill in 2.1, but it doesn't actually cause an error because pt-kill retries its queries, so the first time a child tries to kill something, it fails, reconnects, tries again and succeeds.

The only simple solution I could thing of was:

my $cxn = Cxn->new(
   parent => $o->get('daemonize'),
);

If parent is true in DESTROY, the dbh is not disconnected. Then the child proc has to set $cxn->{parent}=0 after daemonizing. Not the pretties solution, but it works.

Usage of Cxn vs. direct DSNParser is about half-and-half. I originally created Cxn because tools would occasionally die with that "rolling back active statement handle" error when the tool forgot to $dbh->disconnect() or failed to because it crashed. That's why it's done in Cxn::DESTROY(): so it's guaranteed to be done no matter what. Maybe Cxn isn't the best solution given this new bug, but it's in the wild now so if we want another solution, we'll have to find and make the time to create, implement, and test it thoroughly. That probably won't happen for awhile.