2010-11-17 10 views
5

Voy a hacer y responder esta pregunta porque me tomó mucho tiempo resolverlo y desearía que la respuesta hubiera estado aquí para comenzar.Uso de unixODBC en una configuración concurrente multiproceso

El problema: Una consulta unixODBC de larga ejecución bloquea todas las demás de la misma aplicación.

La pregunta: ¿Cómo se puede evitar que esto suceda?

Respuesta

12

La respuesta, en forma de un comentario de cortar y pegar de __handles.c - Lo sé, ¿por qué no todo el mundo piensa en buscar allí la documentación para empezar, ¿verdad?

/* 
* 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) 
* 
*/ 
+0

dejar de usar myisam ?? –

+0

Creo que no entendió el punto. El punto es que uno puede configurar explícitamente el nivel de subprocesamiento para que funcione con controladores que proporcionan cierto grado de seguridad de subprocesos por sí solos. myisam no tiene nada que ver con esto. – sclv

+0

@sclv, gracias! La documentación de unixODBC es sorprendentemente escasa. :/ –

3

Simplemente una adición a esa respuesta. La versión actual de unixODBC 2.3.0 está predeterminada en Threading = 0, por lo que el valor predeterminado ahora es suponer que el controlador es seguro para subprocesos. Esta era una suposición arriesgada en años pasados, no tanto ahora.

+0

Debian 6 todavía usa 2.2. –

0

Si su controlador admite funciones asíncronas, puede habilitarlo y ejecutar las funciones que consumen tiempo en modo asíncrono.

No se requieren hilos en el lado de la aplicación.