On Thu, Jun 27, 2002 at 03:30:00PM +0200, Gerald Richter - ecos gmbh wrote:
> Hi,
>
> as perl Makefile.PL says and my test confirms does DBI & DBD::Orcale not
> work with concurrent threads.
Concurrent iThreads that is - works okay with old 5005threads.
(At least as well as possible with the flawed 5005threads model :)
> I like to use it with mod_perl 2, perl 5.8.0 and ithreads under windows. So
> I have a few question how I might get this working:
>
> - Is the oracle c library under windows thread safe at all? If not, I think
> the only chance we have is to serialize all calls into the oracle c code.
Search the recent archives for ora_init_mode. Connecting with
DBI->connect( ..., { ora_init_mode => N })
helps, where N is the value of OCI_OBJECT | OCI_THREADED.
(The next DBD::Oracle release will do that automatically.)
> - If the orcale code isn't the problem, is it a problem in DBI itself or in
> DBD::Oracle or both?
Apart from the above it's mostly DBI, I think.
> - If it is an DBI/DBD problem are there any known points in the code which
> may cause the problem, require syncronisation etc.
>
> If this points are known I will try to create a patch to get it working
Excellent!
The find the key points in the DBI.xs code, look for these words:
DBI_USE_THREADS, COND, DBI_LOCK, DBI_UNLOCK
Basically the key thing to do is change the existing chunk of code
that does a COND_WAIT(driver) for a new chunk that does SvLOCK(driver).
The DBI_LOCK and DBI_UNLOCK may need to change as well.
Using trace levels >= 4 shows appends the thread number to the trace,
which is very helpful when debugging this stuff.
I'd suggest you copy t/02dbidrv.t to t/03thread.t and hack it so
the data_sources method does a ok();sleep();ok() and then you can
test that only one thread is allowed into the driver.
Test it using 5005threads first before you start hacking DBI.xs and
then switch to iThreads and once it's working you can be fairly
sure all is well.
Many thanks for doing this!
Tim.
