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

No specific coding problem here -- just some issues with making an "upgrade transition". We have Oracle 8.1 on an old sparc server, and perl 5.8.6 on a freebsd web server. For reasons unrelated to Perl, the oracle client software on the bsd box was upgraded to oracle8 (to better match the oracle server), which had the side effect of removing the oracle7 client stuff (which had been working fine for perl/DBI/DBD::Oracle). Oracle's sqlplus and the java/oracle connections are working with the new client software.

Well, time to re-install DBD::Oracle. It turns out perl 5.8.6 on this bsd box was built with threading support turned off, and then it turns out that the current DBD::Oracle seems to want threads turned on. We tried installing DBD::Oracle using the existing perl, but when we ran it, it crashed with a message about how the "Oracle.so" library file contains a reference to a "pthread_kill" symbol, which is undefined at runtime. (That's probably why the build log included this little gem of wisdom: "Warning: If you have problems you may need to rebuild perl with threading enabled.")

Okay, while we're at it, why not move ahead to 5.8.7, which is the common version at the moment for all our other bsd machines. But this would be the only one with threading enabled. (At least, until we decide that all the other machines should make the same change.)

And we're talking about our web server. I would assume that every non-core module with compiled code needs to be resinstalled, which in itself is no problem, but what are the chances of some random module turning freakish, just because we now have threads enabled? (Obviously, none of our scripts are using threads at this point.)

At the very least, I'm looking for guidance on how best to approach this transition. The way it looks to me now, I'm thinking:

- build 5.8.7 with thread support but don't install it - use the CPAN autobundle from the current 5.8.6 to fill in the non-core modules, including DBI - do our best to install DBD::Oracle on 5.8.7, even though this perl isn't fully "installed" the way that the DBD::Oracle readme says it should be - try a bunch of existing apps, including DBI access to oracle8, and assuming they work, do "make install" for 5.8.7
Of course, until that all pans out (or as long as it doesn't), DBI to oracle8 is broken on this machine. (Luckily, it's not in the "critical path".) All suggestions and warnings are welcome.

Replies are listed 'Best First'.
Re: DBD::Oracle and threading on a web server
by perrin (Chancellor) on Mar 03, 2006 at 03:23 UTC
    Building perl with threads will not hurt anything, although it will slow things down (about a 15% performance hit on perlbench). If your applications don't use threads, you don't need to worry about them breaking when run on a threaded perl.
Re: DBD::Oracle and threading on a web server
by BrowserUk (Patriarch) on Mar 03, 2006 at 04:53 UTC

    If I'm reading the error message correctly, you don't need to build a Perl with useithreads in order to fix your compile problem. Assuming I found the right one, the error message your referring to is:

    print "WARNING: Oracle is built with multi-threading libra +ries\n" . " You will most likely need to rebuild perl +from sources\n" . " with the following libraries: -lcl -lpthre +ad\n" ;

    Adding those options won't build a threaded Perl, it just builds it with threadsafe C runtime libraries and the pthread libraries. The resulting Perl will still be non-threaded, and not suffer the performance hit that imposes.

    In any case, if you chose to build a threaded Perl, if DBD::Oracle uses (p)threads under the covers, there is no conflict between that can ithreads. The cloning of Perl data done for spawned iThreads , is a purely Perl affair and will not happen if non-perl library spawns threads--even if that library is dynalinked to a threaded perl.

    Finally, going purely on what I see in the XS and C files for DBD::Oracle, it appears to be iThreads-aware, even if it's not warrented as iThreads-safe.

    In summary, just add the options above to the link command and (re)build your Perl as you would normally and your problems will (or should) just "go away", with no other risks or special considerations.


    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
Re: DBD::Oracle and threading on a web server
by tweetiepooh (Hermit) on Mar 03, 2006 at 11:16 UTC
    Sorry that this may not help too much but we have non-threaded Perl with Oracle::DBD and Oracle8 and Oracle9 clients with no issues like you are reporting. This is on Solaris SPARC v8.

    This may well be something to do with Solaris though.

    The problem we did have is using 64bit Oracle and libraries. Most code puts 32bit in lib and 64bit in lib64. Oracle puts 64bit in lib and 32bit in lib32. You just need to make sure that when building you get the right versions.