jfroebe has asked for the wisdom of the Perl Monks concerning the following question:

I'm writing an application with a business requirement of reconnecting a dead db connection to Sybase through the syb_err_handler() error handler routine.

In the past, I would just run $dbh->DBDEAD() just prior to running the queries. If the connection was dead, I would just reconnect and run the query (plus any initialization db routines).

The syb_err_hander() can easily catch a dead connection but calling $dbh->connect() in the error handler fails

$ ./test_sybase ERROR: Connection dropped ct_config(CS_SET, CS_LOGIN_TIMEOUT) failed at /usr/lib64/perl5/site_pe +rl/5.8.8/x86_64-linux-thread-multi/DBD/Sybase.pm line 94. ct_config(CS_SET, CS_TIMEOUT) failed at /usr/lib64/perl5/site_perl/5.8 +.8/x86_64-linux-thread-multi/DBD/Sybase.pm line 94. ct_con_alloc failed at /usr/lib64/perl5/site_perl/5.8.8/x86_64-linux-t +hread-multi/DBD/Sybase.pm line 94. ERROR: unable to connect to SISDBA

Has anyone done this? I'm starting to think that this can't be done through the error handler of DBD::Sybase

#!/usr/bin/perl use strict; use warnings; use lib "/home/jfroebe/lib"; use DBI; use File::Basename; our $SYBDBA_login = 'login'; our $SYBDBA_password = 'password'; our $dbh = connect_dbms(); sub report_err { my $msg = shift; my $type = shift; if ($type eq 'error') { print "ERROR: $msg\n"; } else { print "MSG: $msg\n"; } } sub syb_err_handler { my($err, $sev, $state, $line, $server, $proc, $msg, $sql, $err_typ +e) = @_; my %ignore_errors = map { $_, 1 } (6, 183, 208, 2056, 2057, 14024, + 17001); if ($err == 151 || $err == 50 || $err == 60) { report_err("Connection dropped", "error"); for (my $attempt = 0; $attempt < 10; $attempt++) { if ($dbh = connect_dbms()) { report_err("Reconnected", "error"); return 0; } sleep 2; } return 1; } elsif ($err == 63 || ($err == 4 && $sev == 5) ) { report_err("Connection timed out", "error"); return 1; } elsif ($ignore_errors{$err}) { # ignore return 0; } print "error: $err, $sev, $state : $msg\n"; return 1; } sub connect_dbms { my $script = basename($0); if ($dbh = DBI->connect("dbi:Sybase:server=SISDBA;loginTimeout=10; +timeout=30;scriptName=$script;encryptPassword=1;tdsLevel=CS_TDS_50;ch +arset=iso_1", $SYBDBA_login, $SYBDBA_password, { PrintError => 0, Rai +seError => 0, syb_err_handler => \&syb_err_handler } )) { return $dbh; } report_err("unable to connect to SISDBA", "error"); return; } sub syb_loop { my $query = "exec sp_helpdb"; for (my $i = 0; $i < 10000; $i++) { my $array_ref = $dbh->selectall_arrayref($query); } } syb_loop();

Update:

I received an email from Michael Peppler, the creator/maintainer of DBD::Sybase. In it, he says that this is a limitation of Sybase's OpenClient CT-Library not DBD::Sybase.

The error handler is called by Sybase's ct_callback() function. Sybase has restricted what CT-Library calls that can be made. Apparently while ct-connect() can be called, memory allocation of the connection will be disallowed.

I'm opening a number of feature requests with Sybase to make reconnecting, when the connection dies, easier to do.

Jason L. Froebe

Team Sybase member

No one has seen what you have seen, and until that happens, we're all going to think that you're nuts. - Jack O'Neil, Stargate SG-1

Replies are listed 'Best First'.
Re: DBD::Sybase - How to reconnect through err_handler
by Bro. Doug (Monk) on Nov 08, 2006 at 01:13 UTC
    I've never worked with Sybase, but I know that DBI has a connect_cached method. It checks a cached connection to find out if its dead before it opens a new connection. I use this often to ensure my db connections (MySQL, Oracle) are valid before running an operation.

    It's a DBI method, so I suggest trying it:
    my $dbh = DBI->connect_cached( ... );

    Hope that helps.

    Bro. Doug :wq

      Good idea, but the DBI->connect_cached() only really applies when you are attempting to make a connection. In my particular situation, where the db connection dies, I have to reconnect within the error handler routine (see the update to the OP for where we're at now).

      Thanks for the idea though :)

      Jason L. Froebe

      Team Sybase member

      No one has seen what you have seen, and until that happens, we're all going to think that you're nuts. - Jack O'Neil, Stargate SG-1

Re: DBD::Sybase - How to reconnect through err_handler
by dk (Chaplain) on Nov 08, 2006 at 09:43 UTC
    I've been asked to do similar things in the past for PgSQL, so you may try the results of my efforts - DBIx::AutoReconnect, or it's bloatier relative, DBIx::Roles::AutoReconnect. These modules detect DBI errors by transparently wrapping all method calls in eval, making them restartable, and check the connection status by calling $dbh->ping() ( vs $dbh->DBDEAD you were using ). I didn't test the logic on Sybase, but I'd like to know if it was useful there.

      That is definitely something to take a look at :), atleast for new development. Merging it into legacy code may be a bit trickier (politically and technically).

      Jason L. Froebe

      Team Sybase member

      No one has seen what you have seen, and until that happens, we're all going to think that you're nuts. - Jack O'Neil, Stargate SG-1

Re: DBD::Sybase - How to reconnect through err_handler
by aufflick (Deacon) on Nov 09, 2006 at 05:39 UTC
    I would do something simple in the callback like setting a global variable like $MyDBI::db_needs_reconnecting.

    Then have your db fraamework (assuming you have some sort of subclass or wrapper on DBI) open a connection before any db access if that variable is set.