MySqlCommand BeginexecuterEader está faltando um parâmetro assíncrono que a renderizando praticamente inútil

Question

Espero que alguém aqui possa me ajudar.

A empresa em que trabalho prefere que eu use o MySQL em vez do MSSQL. Então, baixei o driver mais recente (6.1) e estou portando a camada de banco de dados.

No entanto, não consigo encontrar a função BeginexecuterEader, que exige um retorno de chamada como parâmetro.

Isso é por um motivo? Ou funciona de maneira diferente com o MySQL?

Tanto quanto eu posso ver, se o código não aumentar um retorno de chamada, eu precisaria fazer uma pesquisa, o que o tornará devagar. Usar um fio de bloqueio por conexão também é algo que eu quero evitar.

Alguém ideias como enfrentar isso? (Além de alterar o motorista que provavelmente está além dos meus poderes)

R

Answer 1

A versão 6.3.4 dos conectores MySQL implementa métodos assíncronos, mas parece que ele apenas chama um delegado assíncrono, para que não seja bloqueador para o encadeamento de chamada, mas não salvará nenhum encadeamento do Threadpool. Aqui está o relatório de bug sobre isso.

E, como você disse, ele não possui um parâmetro de retorno de chamada. Aqui está o relatório de bug sobre isso.

Eu acredito Provedores de dados de Devart Implemente os métodos assíncronos corretamente, mas eles não são gratuitos.

De qualquer forma, as chamadas de banco de dados ASYNC não implicam melhor escalabilidade geral por si mesmas. Eu recomendo ler o artigo "Minhas chamadas de banco de dados devem ser assíncronas?"Para uma análise aprofundada.

Answer 2

Não conheço esse conector especificamente, mas todos os outros conectores que eu vi no MySQL apenas aguardam o servidor retornar os dados durante a chamada execute () ou query (). O mais próximo que você conseguirá é usar a versão "não buffer", que retorna imediatamente de Execute () ou Query (), mas bloqueia quando você tenta solicitar a próxima linha, mas ainda não chegou do servidor MySQL.

Answer 3

O suporte do thread do MySQL parece -me basicamente ser uma reflexão tardia.

Você não pode, por exemplo, através da API C, cancelar uma consulta emitida; Em vez disso, a função de consulta simplesmente bloqueia. Para fazer várias consultas simultâneas, é necessário um tópico por consulta!

Tente usar o PostGres. Eu não usei (a API C me adiou - todos esses typedefs), mas certamente possui suporte adequado para consultas com vários threads (por exemplo, chamadas assíncronas, etc.).