perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Randolf Richardson" <>
Subject Re: Problem with long http request generation time - process restarting
Date Fri, 16 Dec 2011 18:20:23 GMT
> Thanks for the responses :)
> However - I just read another thread somewhere that made me think of
> looking in the Event log.
> It appears that the culprit is Oracle - there are errors
> naming OraOCIEI11.dll as the "Faulting Module name".

	That's very interesting.  Windows Event Viewer is a good place to 
look (I keep forgetting about it as I'm used to /var/log/messages in 
Unix/Linux and similar environments).

> Apparently one is not supposed to use DBI in a threaded Perl environment.

	I've been using DBI in threaded Perl environments for many years, 
and it works just fine for me.  I used Oracle 8i in the past on 
NetWare (with ModPerl 1 in a threaded environment because the NetWare 
OS is a thread-based architecture and Apache HTTPd and ModPerl were 
both compiled accordingly), but I switched to PostgreSQL many years 
ago so I'm not up-to-date with the more recent Oracle DBD issues...

	For those experiencing problems with DBI in threaded environments, 
my guess is that it's more likely due to problems with the way the 
environment was set up (possibly even related to compilation?) or, 
more likely, that a developer doesn't really understand threads 
(unfortunately this seems to be fairly common).

	Also, with DBI there are some wonderful features such as 
"connect_cached" and "prepare_cached" that are a huge benefit in 
persistent environments such as ModPerl 2 that also seem to work 
without issues in threaded environments.  These features appear to be 
well-suited for use in persistent multi-threaded environments, but 
it's important to note that one can just use the regular "connect" 
and "prepare" functions too (and that they'll work as expected).

	One way people seem to mess up with programming in a threaded 
environment is that they rely on global variables inappropriately, 
and then have multiple threads using the same variable without 
ensuring atomic operations (e.g., using the same database or 
statement handles simultaneously across separate threads does lead to 
problems).  There are other issues too, but I suspect this type of 
mistake is more common.

> Someone in a PHP system created the Oracle environment and connection using
> a THREADED_MUTEXED option which worked for them.
> Investigation continues...

	Thanks, and please keep us updated (at 
instead of via a private reply).  If Oracle's DBD is doing something 
unexpected, and especially if you do manage to find a solution, that 
could be useful to people who use Oracle.

Randolf Richardson -
Inter-Corporate Computer & Network Services, Inc.
Beautiful British Columbia, Canada

View raw message