After spending a little time with Class::DBI, it appears that it is possible for a database handle with uncommitted transactions to go dead, a new database handle returned, and commit called on the new database handle--resulting in lost transactions of the uncommitted dead handle.

A brief example using Class::DBI's example Music/CD database may help to explain:

for my $cd ( 1 .. 2 ) {
    Music::CD->create(
        {   cdid   => $cd,
            title  => "Title of CD $cd",
            year   => '2006',
            artist => 5,
        }
    );
    for my $track ( 1 .. 5 ) {
        Music::Track->create(
            {   trackid  => $cd . $track,
                cd       => $cd,
                position => $track,
                title    => "Title of track $track",
            }
        );

    }
}
Music::DBI->dbi_commit();

The above results in 13 calls to Ima::DBI's _mk_db_closure, which returns a database handle:

sub _mk_db_closure {
    my ($class, @connection) = @_;
    my $dbh;
    return sub {
        unless ($dbh && $dbh->FETCH('Active') && $dbh->ping) {
            $dbh = DBI->connect_cached(@connection);
        }
        return $dbh;
    };
}

_mk_db_closure and DBI->connect_cached will return the same database handle if the dbh->ping is successful. But if it's not, a new database handle is returned.

If say, on the 8th call to _mk_db_closure, the ping fails, and a new database handle is returned. Wouldn't all uncommited transactions on the dead database handle be silently lost?

I realize that the possibility of the handle going dead, and a new one returned is remote. In practice, if the a handle goes dead, usually the database is down and a new handle won't be able to be created. However, the possibility exists.

So, is it possible that Class::DBI's mulitple potential calls to connect_cached during a single execution could result in lost transactions?

Thank you