Eu discordo de Ricka sobre isso. Os comandos de banco de dados assíncronos não são apenas bons, eles são essenciais para alcançar escala, taxa de transferência e latência. Sua objeção sobre o tempo de aceleração do pool de threads se aplica apenas a um servidor da Web que experimenta volumes de tráfego baixos.
Em uma situação de alto tráfego (que é a única que importa), o pool de threads não terá que esperar pela 'injeção' de novos threads. Fazer os comandos SQL de forma assíncrona é importante não apenas do ponto de vista da integridade das solicitações/threads do servidor web, mas também do ponto de vista do tempo de vida/latência total da solicitação:chamadas de banco de dados não correlacionadas podem ser feitas em paralelo, em vez de sequencialmente. Isso por si só resulta geralmente em melhorias dramáticas na latência da solicitação HTTP conforme experimentada pelo usuário. Em outras palavras, suas páginas carregam mais rápido.
Um conselho:o comando SQL não é verdadeiramente assíncrono até que você habilite
Asynchronous Processing=true
na cadeia de conexão. Enquanto isso não estiver definido (e por padrão não estiver, Editar:começando com .NET Framework <4.5. Asynchronous Processing não é mais necessário
) suas chamadas 'assíncronas' para BeginExecuteReader
não são nada além de uma farsa, a chamada lançará um thread e bloqueará isso fio. Quando o processamento assíncrono verdadeiro está habilitado na string de conexão então a chamada é verdadeiramente assíncrona e o retorno de chamada é baseado na conclusão de E/S. Uma palavra de cautela:um comando SQL assíncrono é concluído assim que o primeiro result retorna ao cliente e as mensagens informativas contam como resultado.
create procedure usp_DetailsTagsGetAllFromApprovedPropsWithCount
as
begin
print 'Hello';
select complex query;
end
Você perdeu todos os benefícios do assíncrono. A
print cria um resultado que é enviado de volta ao cliente, que conclui o comando assíncrono e a execução no cliente continua e continua com o 'reader.Read()'. Agora isso bloqueará até que a consulta complexa comece a produzir resultados. Você pergunta 'quem coloca print no procedimento?' mas o print pode estar disfarçado em outra coisa, talvez algo tão inocente quanto um INSERT que executa sem primeiro emitindo um SET NOCOUNT ON
. 
