The cause of this new warning is withing the perl core itself, caused this commit.

It happens only when using threads and the boot code of DBD::Oracle is called twice.

Then the boot code tries to re-install the oracle specific methods and constants using DBI's internal install_method call.

You can indeed suppress that warning in DBI.pm, using something similar to

    my (undef, $filename, $line) = caller;
    # XXX reformat $attr as needed for _install_method
    my %attr = %{$attr || {}}; # copy so we can edit
    {   no warnings "redefine";
        DBI->_install_method ("DBI::${subtype}::$method", "$filename a
+t line $line", \%attr);
        }
[download]

but that sweeps the warning under the carpet.

narrowing the scope, the warning is generated from the call cv = newXS_flags (meth_name, XS_DBI_dispatch, file)<c> in <c>DBI.xs in _install_method.

My personal opinion is that the boot code of DBD::Oracle is wrong, but at this moment, I have no idea of how to fix that.

Thanks for that code to suppress warnings. It worked.

Not ideal, i.e. it does sweep the issue under the carpet. However, buys me some time to find a more elegant solution - and keep the latest code.

Note - l did revert from 5.40.2 to 5.38.4 (from 5.38.0), and will try to upgrade again in a couple of months time.

I have joined the DBI Mailing List to post the issue, but am waiting to get the permissions to raise it

I think you could also address the issue by only loading DBI from the code executing in the threads.

Did you change your code at all? It looks like a module is getting included twice. It's strange how the Oracle functions are showing up in the DBI namespace.

0% change in the application code - except for the attempts to remove the "redefine"'s.

I just upgraded Perl, then the DBI/ DBD Oracel modules to the latest ones.

I looked up line 1398 in the DBI.pm, and it contains below. It has not changed between versions.

Going to see what else l can do before reverting to a previous version of the DBI module.

DBI-1.647 - Causes Redefines

 sub install_method {
        # special class method called directly by apps and/or drivers
        # to install new methods into the DBI dispatcher
        # DBD::Foo::db->install_method("foo_mumble", { usage => [...],
+ options => '...' });
        my ($class, $method, $attr) = @_;
        Carp::croak("Class '$class' must begin with DBD:: and end with
+ ::db or ::st")
            unless $class =~ /^DBD::(\w+)::(dr|db|st)$/;
        my ($driver, $subtype) = ($1, $2);
        Carp::croak("invalid method name '$method'")
            unless $method =~ m/^([a-z][a-z0-9]*_)\w+$/;
        my $prefix = $1;
        my $reg_info = $dbd_prefix_registry->{$prefix};
        Carp::carp("method name prefix '$prefix' is not associated wit
+h a registered driver") unless $reg_info;

        my $full_method = "DBI::${subtype}::$method";
        $DBI::installed_methods{$full_method} = $attr;

        my (undef, $filename, $line) = caller;
        # XXX reformat $attr as needed for _install_method
        my %attr = %{$attr||{}}; # copy so we can edit
        DBI->_install_method("DBI::${subtype}::$method", "$filename at
+ line $line", \%attr); <b># Line causing the redefine</b>
    }
[download]

DBI-1.643 - No Redefine

sub install_method {
        # special class method called directly by apps and/or drivers
        # to install new methods into the DBI dispatcher
        # DBD::Foo::db->install_method("foo_mumble", { usage => [...],
+ options => '...' });
        my ($class, $method, $attr) = @_;
        Carp::croak("Class '$class' must begin with DBD:: and end with
+ ::db or ::st")
            unless $class =~ /^DBD::(\w+)::(dr|db|st)$/;
        my ($driver, $subtype) = ($1, $2);
        Carp::croak("invalid method name '$method'")
            unless $method =~ m/^([a-z][a-z0-9]*_)\w+$/;
        my $prefix = $1;
        my $reg_info = $dbd_prefix_registry->{$prefix};
        Carp::carp("method name prefix '$prefix' is not associated wit
+h a registered driver") unless $reg_info;

        my $full_method = "DBI::${subtype}::$method";
        $DBI::installed_methods{$full_method} = $attr;

        my (undef, $filename, $line) = caller;
        # XXX reformat $attr as needed for _install_method
        my %attr = %{$attr||{}}; # copy so we can edit
        DBI->_install_method("DBI::${subtype}::$method", "$filename at
+ line $line", \%attr);
    }
[download]

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);
        }
[download]

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.

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?