I am going to ask and answer this question because I needed to find out forever, and I want the answer here to begin.
Problem: One long-running unixODBC request blocks all others from one application.
Question: how to stop it?
The answer is in the form of a cut-paste comment from __handles.c. I know why not everyone thinks that looking for documentation there to begin with, right?
/* * use just one mutex for all the lists, this avoids any issues * with deadlocks, the performance issue should be minimal, if it * turns out to be a problem, we can readdress this * * We also have a mutex to protect the connection pooling code * * If compiled with thread support the DM allows four different * thread strategies * * Level 0 - Only the DM internal structures are protected * the driver is assumed to take care of it self * * Level 1 - The driver is protected down to the statement level * each statement will be protected, and the same for the connect * level for connect functions, note that descriptors are considered * equal to statements when it comes to thread protection. * * Level 2 - The driver is protected at the connection level. only * one thread can be in a particular driver at one time * * Level 3 - The driver is protected at the env level, only one thing * at a time. * * By default the driver open connections with a lock level of 3, * this can be changed by adding the line * * Threading = N * * to the driver entry in odbcinst.ini, where N is the locking level * (0-3) * */
. unixODBC 2.3.0 - Threading = 0, , . , .
If your driver supports asynchronous functions, you can enable it and run a lot of time in async mode.
No threads are required on the application side.