You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Geoffrey Young <ge...@modperlcookbook.org> on 2002/08/21 19:32:42 UTC
DBD::Oracle problem
>
> people have problems with the Oracle DBD driver and 'SetHandler
> perl-script' See http://mathforum.org/epigone/modperl/lumfrahku
>
sorry, but I don't have the old thread in my inbox, so I can't reply
to it.
when you chose to print out ORACLE_HOME from Oracle.pm you were
actually looking in the wrong place. DBD::Oracle requires that
ORACLE_HOME (and any other stuff like NSL_LANG stuff) be in %ENV when
DBD::Oracle is compiled (read: first use()d or loaded on demand by
DBI.pm).
so, you need to make sure that wherever that load happens %ENV is
properly set.
I'm not sure what's possible now with mod_perl 2.0 wrt startup.pl and
<Perl> blocks, but you might want to do something like put that BEGIN
block in your startup.pl instead, followed by
use DBD::Oracle;
use DBI;
or play with the profile for root, nobody, /etc/profile etc to make
sure that $ENV{ORACLE_HOME} and friends get populated properly.
you also might want to remove the NSL stuff for the moment and see if
you can get things working without it. IIRC there was some stuff on
the DBI users list (a _very_ long time ago) where NSL in %ENV was the
issue, so maybe boiling down stuff will help you locate the problem
(and help us see what is required on the mod_perl side in order to fix
things).
HTH
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: DBD::Oracle problem
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
>
> But Atsushi and the other guy with this problem were able to have this
> working under 'SetHandler modperl' that's the weird part, that makes me
> wonder why?
>
ok, I didn't catch that when I re-read the thread.
the order of Perl module loading between modperl and perl-script might
be a good place to look, then - stuff like how modules are loaded,
when BEGIN blocks execute, and so on. anything that would change
whether DBD::Oracle could see %ENV (and whose %ENV?) when it (or DBI)
is put in memory.
my thought in re-reading the thread was that DBD::Oracle needs
$ENV{ORACLE_HOME} when it's compiled, which I didn't see anyone
mention. I think that may be a key point. it kinda stuck out, I
guess - I don't know if it's the actual cause or not :)
sorry I can only speculate here, not being familiar with the
destinctions (documented or not) between the two mod_perl 2 handlers.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: DBD::Oracle problem
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>
>>
>> people have problems with the Oracle DBD driver and 'SetHandler
>> perl-script' See http://mathforum.org/epigone/modperl/lumfrahku
>>
>
>
> sorry, but I don't have the old thread in my inbox, so I can't reply to it.
> when you chose to print out ORACLE_HOME from Oracle.pm you were actually
> looking in the wrong place. DBD::Oracle requires that ORACLE_HOME (and
> any other stuff like NSL_LANG stuff) be in %ENV when DBD::Oracle is
> compiled (read: first use()d or loaded on demand by DBI.pm).
But Atsushi and the other guy with this problem were able to have this
working under 'SetHandler modperl' that's the weird part, that makes me
wonder why?
> so, you need to make sure that wherever that load happens %ENV is
> properly set.
>
> I'm not sure what's possible now with mod_perl 2.0 wrt startup.pl and
> <Perl> blocks, but you might want to do something like put that BEGIN
> block in your startup.pl instead, followed by
>
> use DBD::Oracle;
> use DBI;
>
> or play with the profile for root, nobody, /etc/profile etc to make sure
> that $ENV{ORACLE_HOME} and friends get populated properly.
>
> you also might want to remove the NSL stuff for the moment and see if
> you can get things working without it. IIRC there was some stuff on the
> DBI users list (a _very_ long time ago) where NSL in %ENV was the issue,
> so maybe boiling down stuff will help you locate the problem (and help
> us see what is required on the mod_perl side in order to fix things).
>
> HTH
>
> --Geoff
>
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: DBD::Oracle problem
Posted by Doug MacEachern <do...@covalent.net>.
the issue is that environ[] is not thread safe. so mod_perl2 unties %ENV
from the underlying environ[] array under the perl-script handler.
i assume the oracle driver or client library uses getenv() (which fetches
from the environ[] array). when %ENV is untied from environ[], perl-land
will see %ENV changes, but C-land will not see the coresponding changes
in environ[].
the 'modperl' handler does not untie %ENV from environ[].
so, one should avoid setting %ENV values whenever possible.
and if it is required, should be done at startup time.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org