A MySQLCommand BeginExecuteReader le falta un parámetro AsyncCallback que lo hace prácticamente inútil

Question

Espero que alguien aquí pueda ayudarme.

La compañía para la que trabajo preferiría usar MySQL en lugar de MSSQL. Así que descargué el último controlador (6.1) y estoy portando la capa DB.

Sin embargo, no puedo encontrar la función BeginExecuteReader que toma una devolución de llamada como parámetro.

¿Es esto por alguna razón? ¿O funciona de manera diferente con MySQL?

Hasta donde puedo verlo, si el código no genera una devolución de llamada, necesitaría una encuesta que lo hace lento. Usar un hilo de bloqueo por conexión también es algo que quiero evitar.

¿Alguien tiene idea de cómo abordar esto? (aparte de alterar el controlador que probablemente esté más allá de mis poderes)

R

Answer 1

La versión 6.3.4 de MySQL Connector implementa métodos asíncronos, pero parece que solo invoca a un delegado de forma asincrónica, por lo que no bloqueará el hilo de llamada, pero no guardará ningún hilo del ThreadPool. Aquí está el informe de error al respecto .

Y, como dijiste, no tiene un parámetro de devolución de llamada. Aquí está el informe de error al respecto .

Creo que los proveedores de datos de devart implementan métodos asíncronos correctamente, pero no son gratuitos.

De todos modos, las llamadas a bases de datos asíncronas NO implican una mejor escalabilidad general por sí mismas. Recomiendo leer el artículo " ¿Deben las llamadas de mi base de datos ser asíncronas? " para un análisis en profundidad.

Answer 2

No conozco este conector específicamente, pero cualquier otro conector que haya visto para mysql solo espera a que el servidor devuelva los datos durante la llamada execute () o query (). lo más cerca que estará es usar el " sin búfer " versión, que regresa inmediatamente de execute () o query (), pero se bloquea cuando intenta solicitar la siguiente fila pero aún no ha llegado del servidor mysql.

Answer 3

El soporte de hilos MySQL me parece básicamente una idea de último momento.

No puede, por ejemplo, a través de la API de C, cancelar una consulta emitida; más bien, la función de consulta simplemente bloquea. Para realizar múltiples consultas concurrentes, ¡se requiere un hilo por consulta!

Intenta usar Postgres. No lo he usado (la API de C me desanimó, todos esos typedefs), pero ciertamente tiene el soporte adecuado para consultas multiproceso (por ejemplo, llamadas asíncronas, etc.).