Zeoslib Portal

Hi,

I am using Zeos 8.0 from Delphi 10.3 in an ETL-Type application where I fetch data from a REST-API and pump it into an Oracle DB. I have set things up so that various REST endpoints can be serviced from separate threads.

Unfortunately this fails by throwing an EExternalException. The oracle client also barfs the string KPEDBG_HDL_POP_FCPTR to stdout. So I believe the error is triggered in 3dparty code by Oracle.

My TZConnection all Zeos-Components are on DataModules. These are instantiated in the context of the main thread during setup but I am positive that I am creating a separate instance of the datamodule for each thread spawned later. When instantiating the datamodules I specify an Owner of NIL.

I have also tried creating the datamodules from within the worker threads themselves. But that results in the same error.

I do not have a simple testcase and am aware that this may be caused by a lot of dumb things I did wrong.

But maybe there is a something specific I need to tell the Oracle client that I want to use it in a multithreaded application?

Regards, Marian

Hi Marian.

Try adding the following connection property to see if it helps your case:

MyConn.Properties.Values[ConnProps_OCIMultiThreaded] := 'True';

This puts the Oracle Client into multithreading mode.

-Mark

MJFShark wrote: ↑10.07.2024, 11:33MyConn.Properties.Values[ConnProps_OCIMultiThreaded] := 'True';

You beat me to it :) Me too, about 95% sure this will solve OP's issue.

Yes, that did the trick.

To be precise I set the connection property at design time using the visual editor, but the result obviously is the same.

I would like to apologize for my weak googling, especially as I had a hunch it might be something like this.

Thank you very much!

Regards, Marian

However the patch is almost 2 years old it doesn't get much visibility because of two reasons:
- It does not affect single-threaded applications
- Even multithreaded ones can run stable-ish without it with specific driver versions

Plus, for months I simply considered these errors as normal operation for the crap Oracle calls driver :)