Results 1 to 2 of 2
  1. #1
    Join Date
    Mar 2005
    Posts
    2

    Unanswered: Problems using OCI / OCCI in multithreaded environment

    Hi

    I have developed an application in C++ that runs multiple threads on multiple OS's (WinXp, Linux, UNIX). Each thread opens a separate session to the database (OCIServerAttach then OCISessionBegin). In the main application thread I create an environment handle with OCI_THREADED mode (OCIEnvCreate). This handle is then passed to each thread.

    Each thread call various SQL stored procedures with 1 or more parameters.
    The problem is: when the number of runnig threads is growing, in Oracle db the stored procedures called from my threads have NULL parameters. But I never send NULL parameters, I checked that very clearly.

    I managed to save the problem using OCCI instead of OCI. But here I have another problem: I cannot compile OCCI on UNIX AIX with gcc !!! . I installed last version of gcc from gcc.gnu.org (3.4.3) and no chance. From what I read on the other forums it seems that gcc does not support OCCI on UNIX AIX only a dedicated compiler xlc++. Indeed I downloaded a trial version and is working in this way, but this is not a solution for me because I cannot spend 3.000 USD on this compiler.

    So I'm stuck. I see 2 options:

    1. Make the application run properly with OCI
    2. Workaround in order to compile OCCI on UNIX AIX (5.2)

    I would appreciate help on any of these solutions.

    Marius

  2. #2
    Join Date
    Aug 2004
    Location
    France
    Posts
    754
    Sorry I can't help you for your problem , but I think I can give you a piece of performance advice.

    As you've certainly seen in the OCI or OCCI docs, all objects created by a single environment MUST be serialized (be it you choose THREADED_MUTEXED or THREADED_UNMUTEXED mode in OCCI), and as you must know SERIALIZATION is a performance KILLER. Having a single environment means that each time ONE SESSION is active, ALL the other ones must stay inactive ! (and I've tested it, this is so). For me, the only viable solution speaking of performance is having one environment per thread, and only one connection (session) per environment, even if it takes more memory. Hell, this is what threads are all about : parallelism ! Conclusion : don't share your environment handler if you want parallel execution of your queries (this is the reason why you're using threads, isn't it ? ).

    As I said, it's just a piece or advice, leave it or take it.

    Hope that helps,

    Regards,

    RBARAER

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •