File perl-DBIx-RetryOverDisconnects.spec of Package perl-DBIx-RetryOverDisconnects

# spec file for package perl-DBIx-RetryOverDisconnects
# Copyright (c) 2019 SUSE LINUX GmbH, Nuernberg, Germany.
# All modifications and additions to the file contributed by third parties
# remain the property of their copyright owners, unless otherwise agreed
# upon. The license for this file, and modifications and additions to the
# file, is the same license as for the pristine package itself (unless the
# license for the pristine package is not an Open Source License, in which
# case the license is the MIT License). An "Open Source License" is a
# license that conforms to the Open Source Definition (Version 1.9)
# published by the Open Source Initiative.

# Please submit bugfixes or comments via

Name:           perl-DBIx-RetryOverDisconnects
Version:        0.12
Release:        0
%define cpan_name DBIx-RetryOverDisconnects
Summary:        DBI wrapper that helps to deal with databases connection problems
License:        Artistic-1.0 OR GPL-1.0-or-later
Group:          Development/Libraries/Perl
Url:  {cpan_name}
Source1:        cpanspec.yml
BuildArch:      noarch
BuildRoot:      %{_tmppath}/%{name}-%{version}-build
BuildRequires:  perl
BuildRequires:  perl-macros
BuildRequires:  perl(DBI) >= 1.44
BuildRequires:  perl(Exception::Class) >= 1.23
Requires:       perl(DBI) >= 1.44
Requires:       perl(Exception::Class) >= 1.23

This wrapper intercepts all requests. If some request fails this module
detects the reason of fail. If the reason was database connection problem
then wrapper would automatically reconnect and restart the query. Otherwise
it would rethrow the exception.

If you are not in transaction then you can just do


This might have 2 fatal cases:

  * SQL error (a good reason to die).

  * Reconnect retries limit reached (database is completely down or network

For example, if the connection to database were lost during 'execute' call,
the module would reconnect to database with a timeout 'ReconnectTimeout'.
If reconnect failed it would reconnect again 'ReconnectRetries' times with
'ReconnectInterval' interval (in seconds). If reconnect retries limit was
reached it would raise an error and $dbh->is_fatal_disconnect would be

If you are in transaction then even DB disconnect will raise an error. But
you can check $dbh->is_trans_disconnect and restart the transaction if it
is 'true'. Other possible errors are the same: sql error and reconnect

The recommended way of using transactions is


because 'txn_do' would automatically restart the transaction if it was
failed because of database disconnect. The transaction can be restarted at
most 'TxnRetries' times. If 'TxnRetries' limit was reached then error would
be raised and $dbh->is_fatal_trans_disconnect set to true. Other error
cases are the same as above.

'txn_do' would try do to rollback if there was a perl or sql error (no
rollback needed when you loose connection to database: DB server already
has done it). Rollback is successul when $@ =~ /Rollback OK/;

Note: For the perfomance reasons, DBI attribute 'RaiseError' is always set
to 'true'.

%setup -q -n %{cpan_name}-%{version}

make %{?_smp_mflags}

make test


%files -f %{name}.files
%doc Changes test.plx

openSUSE Build Service is sponsored by