On Fri, Jun 07, 2002 at 11:12:41AM +0200, Jrmy JUST wrote:
>
> Thank you for your answer. I should have read the new doc...
>
> >It is I<possibly> safe to have multiple threads load
> >the DBI module I<after> they have been created, but the DBI probably
> >won't be providing any protection against multiple threads entering a
> >databases own library code. As many databases don't have thread
> >safe libraries that is likely to cause problems.
>
> I've tried with DBD-Oracle-1.12 (and Oracle-8.1.5). I load DBI
> and DBD in each thread, in an "eval" statement, hoping that that
> will force separate loading for each thread (am I wrong?);
Depends on how you're doing it.
> but I get a core dump after a few minutes of execution, in a very
> reproducible manner.
Please try doing:
DBI->connect( ..., {
ora_init_mode => N,
});
Where N is the value of OCI_OBJECT + OCI_THREADED.
You can get those values from the Oracle header files (probably
$ORACLE_HOME/rdbms/demo/*.h - I don't have ready access to the
header files to find the values for you.)
> As a last try, I will write a small "wrapper" to protect the DBI module from
>concurrent access: each method that begins a request will put a lock on the driver,
>each one that ends a request will unlock it.
> That won't be a very robust protection, but that may help...
>
> If that works (?!?), I will post my small module to the list.
A combination of loading the DBI into separate interpreters plus
using the ora_init_mode might be good enough. Try it first.
> >Summary: Using DBI with perl threads of any kind is not recommended
> >for production environments.
>
> That seems true...
It's probably not a big job to fix the DBI internals to work with the
new threading model.
I'm unlikely to have the time or motivation to do that soon unless
some business that needs it can sponsor the work. (The recent
DBI::Profile work was sponsored, for example, as are some performance
enhancements I'm working on now.)
Meanwhile patches are welcome.
Tim.
