6

理解するのに永遠にかかったので、この質問に答えます。最初から答えがここにあればよかったのにと思います。

問題: 実行時間の長い 1 つの unixODBC クエリが、同じアプリケーションから他のすべてのクエリをブロックします。

質問: どうすればこれを防ぐことができますか。

4

3 に答える 3

15

答えは、__handles.c からのカット アンド ペースト コメントの形式です。なぜ誰もが最初にドキュメントを探しようとしないのでしょうか。

/*
 * 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)
 *
 */
于 2010-11-17T17:49:42.780 に答える
3

その答えへの単なる追加。unixODBC 2.3.0 の現在のリリースでは、デフォルトで Threading = 0 になっているため、現在のデフォルトでは、ドライバーがスレッド セーフであると想定されています。これは、過去数年間は危険な仮定でしたが、現在はそうではありません。

于 2011-06-10T10:36:57.033 に答える
0

ドライバーが非同期関数をサポートしている場合は、それを有効にして、時間のかかる関数を非同期モードで実行できます。

アプリケーション側にスレッドは必要ありません。

于 2012-05-03T10:46:32.377 に答える