What are the advantages of using DBIx::Connector over simply setting mysql_auto_reconnect to 1?

When dealing with persistant MySQL connections, the one problem is that they get dropped after a certain timeout (usually 28800 seconds). DBIx::Connector seems to do the job of automatically reconnecting to a dropped connection, but it adds more Perl code to each SQL statement which can get annoying. For example instead of:

    $dbh->do('DROP DATABASE stackoverflow');

One has to say:

    $conn->run(
        fixup => sub {
            my $dbh = shift;
            $dbh->do('DROP DATABASE stackoverflow');
        }
    );

Suppose one does not need transactions. Why would one want to use DBIx::Connector instead of passing $dbh->{mysql_auto_reconnect} = 1, which does also work well?

Answers


  1. DBIx::Connector's stated goal is to provide a fork- and thread-safe implementation of DBI's connect_cached(). So you're almost asking an apples/oranges question.

    However, DBIx::Connector does also reconnect if the connection is lost, when it is running in either its ping or fixup Connection Modes. Note that the default is the no_ping mode, which apparently does not attempt reconnection.

  2. DBIx::Connector will work with any DB backend, not just MySQL.

All said... if you're using MySQL, and don't care about the other advantages of DBIx::Connector (because you never fork or use threads, for instance), then mysql_auto_reconnect is probably perfect for you.


Need Your Help


About UNIX Resources Network

Original, collect and organize Developers related documents, information and materials, contains jQuery, Html, CSS, MySQL, .NET, ASP.NET, SQL, objective-c, iPhone, Ruby on Rails, C, SQL Server, Ruby, Arrays, Regex, ASP.NET MVC, WPF, XML, Ajax, DataBase, and so on.