Re: Cannot Remove Redefined Warnings

[Sukhster]

Investigation continues. The issue is running the subroutine in separate threads. And when l wrote this some years ago, l put a comment about the following code.

It looks like this code no longer works, i.e. the refined warnings continue. It is the connect_to_database code that is triggering the redefin warnings.

I removed use warnings altogether, replaced the code below with no warnings in different varieties - but CANNOT remove the redefined warnings.

Any suggestions? I need each thread to hold a separate connection to the database.

######################################################################
+#########
# Function:     connect_to_database
# Purpose:      Connect to the Oracle database
# Arguments:    $db_uid, $db_pwd, $db_sid
# Returns:      $dbh
######################################################################
+#########
sub connect_to_database($$$)
{
        # Declare the variables
        my ($db_uid, $db_pwd, $db_sid) = @_;
        my $dbh;
        my %attribs = (
                PrintError => 0,
                AutoCommit => 0,
                RaiseError => 0
                );

        $dbh = DBI->connect("DBI:Oracle:".$db_sid, $db_uid, $db_pwd , 
+\%attribs )
                or  die "ERROR: Can't connect to database ($db_uid\@$d
+b_sid): ".$DBI::errstr."\n";

        return $dbh;
}

.....
        # Remove erroneous "subroutine redefined" warning
        {
                BEGIN { $^W = 0 }
                $dbh = connect_to_database($db_uid, $db_pwd, $db_sid);
        }

[Corion]

Ideally, you only ever use a single thread to connect to Oracle, as many C libraries (and that includes database drivers) are not thread-safe.

If you really want to use multiple threads to connect to Oracle simultaneously, you need to make sure that every thread initializes its own, separate database connection.

It might be that you already are doing this and that connect_to_database (resp. the code in DBI) installs new subroutines. Then another approach could be to connect to the database once, before spawning any thread, and close that connection again. This could make the Perl setup happen. Closing the database handle again means that your other threads will not stomp on each other, reusing the master connection.

[NERDVANA]

A threading problem makes sense. Threading doesn't get nearly as much community testing because people usually use process-level workers. What if you make sure DBD::Oracle is loaded by the main thread prior to forking?