view release on metacpan or  search on metacpan

lib/DBIx/RetryConnect.pm  view on Meta::CPAN

package DBIx::RetryConnect;
$DBIx::RetryConnect::VERSION = '0.002002';
=head1 NAME

DBIx::RetryConnect - automatically retry DBI connect() with exponential backoff

=head1 SYNOPSIS

    use DBIx::RetryConnect qw(Pg);    # use default settings for all Pg connections

    use DBIx::RetryConnect Pg => sub { {} }; # same as above

    use DBIx::RetryConnect Pg => sub {   # set these options for all Pg connections
        return { total_delay => 300, verbose => 1, ... }
    };

    use DBIx::RetryConnect Pg => sub { # set options dynamically for Pg connections
        my ($drh, $dsn, $user, $password, $attrib) = @_;

        # return undef to not retry for this connection

        # don't retry unless we're connecting to a specific database
        return undef if $dsn !~ /foo/;

        # don't retry for errors that don't include "server" in the message
        return undef if $drh->errstr !~ /server/i;

        # or return a hash ref containing the retry options to use
        return { ... };
    };

=head1 DESCRIPTION

The DBIx::RetryConnect module arranges for failed DBI connection attempts to be
automatically and transparently retried for a period of time, with a growing
delay between each retry.

As far as the application is concerned there's no change in behaviour.
Either the connection succeeds at once, succeeds sometime later after one or
more retries, or fails after one or more retries. It isn't aware of the retries.

The DBIx::RetryConnect module works by loading and I<monkey patching> the connect
method of the specified driver module. This allows it to work cleanly 'under the
covers' and thus avoid dealing with the complexities of C<connect_cached>,
C<dbi_connect_method>, C<RaiseError> etc. etc.

=head2 Multiple Usage

When DBIx::RetryConnect is used to configure a driver, the configuration is
added to a list of configurations for that driver.

When a connection fails for that driver the list of configuration code refs is
checked to find the first code ref that returns a hash reference. That hash is
then used to configure the retry behaviour for that connection retry.

=head2 Randomization

Wherever the documentation talks about the duration of a delay the I<actual>
delay is a random value between 75% and 100% of this value. This randomization
helps avoid a "thundering herd" where many systems might attempt to reconnect
at the same time.

=head2 Options

=head3 total_delay

The total time in seconds to spend retrying the connection before giving up
(default 30 seconds).

This time is an approximation. The actual time spent may overshoot by at least
the value of L</max_delay>, plus whatever time the connection attempts themselves
may take.

=head3 start_delay

The duration in seconds of the initial delay after the initial connection
attempt failed (default 0.1).

=head3 backoff_factor

For each subsequent attempt while retrying a connection the delay duration,
which started with L</start_delay>, is multiplied by L</backoff_factor>.

The default is 2, which provides the common "exponential backoff" behaviour.
See also L</max_delay>.

=head3 max_delay

The maximum duration, in seconds, for any individual retry delay. The default
is the value of L</total_delay> divided by 4. See also L</backoff_factor>.

=head3 verbose

Enable extra logging.