Hi everyone. I have this big problem. Im using db2 through CLI API in a (linux) multiprocess program (that also uses multithreading). The problem begins when the main program forks 3 o 4 processes that try to connect independetly to db2 calling the SQLConnect() function. Im not sure why, but eventually all the processes except one stay locked after calling that function. I used gdb tool to see whats going on on such processes, and I found out that all of them are locked on a pthread_mutex.
I know the description is somehow general to give exact solutions, but do you have any idea what could be wrong? Are the processes waiting for the server to response?

thanks in advance
Federico

DB2 need to know that you are multi threaded. There is a CLI call to tell db2 that it is multi threaded. The Call is " sqleSetTypeCtx(SQL_CTX_MULTI_MANUAL);"

Then when multiple threads try to acess db2 you need to make sure you set the context accordingly.

Ive solved my problem. The thing is that i was executing code after the fork() call with out doing any exec() (in particular, db2 cli api calls). That caused problems with the threads that are embedded in the db2 library. According to the linux documentation, its not advisable to do a fork() without an exec() when using multithreading libraries (basically, the status variables of the mulitithreaded library are inconsistent in the child thread, this includes mutex variable that the library might have created). So now I changed to to an exec() asap after the fork() calling a complete new program.

frusconi, thanks for your reply. but as far as im concerned, db2 cli DOES support mulitthreading by default (say, it initializes different contexts so api calls are thread-safe).