error al usar multiproceso y mysqldb

error al obtener datos de acceso al progtwig de multitreadores.

Exception in thread Thread-2: ProgrammingError: (2014, "Commands out of sync; you can't run this command now") Exception in thread Thread-3: ProgrammingError: execute() first 

De acuerdo con PEP 249 , los módulos de acceso a datos tienen una threadsafety constante a nivel de módulo:

Constante de enteros que indica el nivel de seguridad de subprocesos que admite la interfaz. Los valores posibles son:

0 Los hilos no pueden compartir el módulo.
1 Los hilos pueden compartir el módulo, pero no las conexiones.
2 hilos pueden compartir el módulo y las conexiones.
3 hilos pueden compartir el módulo, conexiones y cursores.

Compartir en el contexto anterior significa que dos subprocesos pueden usar un recurso sin envolverlo con un semáforo mutex para implementar el locking de recursos. Tenga en cuenta que no siempre puede hacer que los subprocesos de recursos externos sean seguros al administrar el acceso mediante un mutex: el recurso puede depender de variables globales u otras fonts externas que estén fuera de su control.

Según la Guía del usuario de MySQLdb , el módulo admite el nivel 1.

El protocolo MySQL no puede manejar múltiples hilos usando la misma conexión a la vez. Algunas versiones anteriores de MySQLdb utilizaron el locking para lograr una seguridad de subprocesos de 2. Si bien esto no es terriblemente difícil de lograr con la clase de cursor estándar (que usa mysql_store_result ()), es complicado por SSCursor (que usa mysql_use_result (); debe asegurarse de que todas las filas hayan sido leídas antes de que se pueda ejecutar otra consulta. Se complica aún más al agregar transacciones, ya que las transacciones comienzan cuando un cursor ejecuta una consulta, pero terminan cuando COMMIT o ROLLBACK es ejecutado por el objeto Connection. los hilos simplemente no pueden compartir una conexión mientras una transacción está en curso, además de no poder compartirla durante la ejecución de la consulta. Esto complica excesivamente el código hasta el punto en que simplemente no vale la pena.

El resultado general de esto es: No compartir conexiones entre hilos. Realmente no vale la pena ni su esfuerzo ni el mío, y al final, probablemente afectará el rendimiento, ya que el servidor MySQL ejecuta un subproceso separado para cada conexión. Ciertamente, puede hacer cosas como las conexiones de caché en un grupo y dar esas conexiones a un hilo a la vez. Si deja que dos subprocesos usen una conexión simultáneamente, la biblioteca del cliente MySQL probablemente se levantará y morirá. Usted ha sido advertido.

Aquí hay detalles sobre el error: http://dev.mysql.com/doc/refman/5.0/en/commands-out-of-sync.html .

El manual de Mysqldb sugiere estos:

No compartas conexiones entre hilos. Realmente no vale la pena ni su esfuerzo ni el mío, y al final, probablemente afectará el rendimiento, ya que el servidor MySQL ejecuta un subproceso separado para cada conexión. Ciertamente, puede hacer cosas como las conexiones de caché en un grupo y dar esas conexiones a un hilo a la vez. Si deja que dos subprocesos usen una conexión simultáneamente, la biblioteca del cliente MySQL probablemente se levantará y morirá. Usted ha sido advertido.

Para aplicaciones con hilos, intente utilizar un grupo de conexiones. Esto se puede hacer usando el módulo Pool.

Vea más información, busque la palabra clave threadsafety en el manual MySQLdb ,

Gracias a tus pocas informaciones, solo puedo adivinar.

Probablemente accedas a la base de datos desde varios hilos sin bloquear. Eso es malo.

Debe mantener un locking en un threading.Lock() o threading.RLock() al acceder a su DB. Esto evita que varios hilos interfieran con las acciones de otros hilos.