Our application suite frequently has code that spawns a new worker thread. Most of the time the worker thread does a lot of database retrieval. I just ported one such block of code to Visual C++ 2005. and the Oracle 10g client. Initially there were problems with the worker and main threads colliding with database connection. I fixed this by explicitly using Oracle Pro*C directives to manage separate database contexts.
There was one operation that gave me a lot of trouble. Part of the problem was that the worker thread interacted heavily with the main thread. At first I just implemented the brute force fix to put all the database calls in a separate context. However this resulted in a lot of Oracle run time errors. For a while this stumped me. Then I realized that some of the database work was actually done in the main thread. So I needed to modify some of the calls to use the database context for the main thread. Perhaps the problems stem from a tricky design that passes control back and forth between main and worker thread. Or maybe I was not paying close enough attention to the thread that was executing database code. I am just happy that this final problem has been resolved.
Now I need to get a release version of the code to build and run. But that is a story for another post.
Package Access Mystery Solved - I have been playing around with the DBMS_CRYPTO package, trying to generate a lot of hashes. I want to study the distribution of hashes for different inpu...