The problem: One long-running unixODBC query blocks all others from the same application.
Odbc Thread level should be set:
/*
* 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's 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)
*
*/
See
http://stackoverflow.com/questions/4207458/using-unixodbc-in-a-multithreaded-concurrent-setting
Recommended UnixODBC settings for postgres
[postgresql]
Description = General ODBC for PostgreSQL Driver = /usr/lib64/libodbcpsql.so Setup = /usr/lib64/libodbcpsqlS.so FileUsage = 1 # Since 1.6 if the driver manager was built with thread support you may add another entry to each driver entry. # This entry alters the default thread serialization level. Threading = 2
Comments
1 comment
Thanks for sharing.
Check it out. https://theopinionatedindian.com/how-to-find-social-activity-spots-to-interact-with-people-in-your-city/
Please sign in to leave a comment.