Quelle est l'avantage d'utiliser le traitement asynchrone dans SQL Server sur le traitement asynchrone .NET? Ne sont-ils pas les mêmes? J'ai du mal à comprendre quel est l'avantage d'utiliser le traitement asynchrone dans SQL Server au lieu de .NET APM. Je peux facilement envelopper un appel SQL dans une expression de Lambda et faire un débutant (...).
Quelqu'un peut-il m'aider la différence et le bénéfice des deux?
5 Réponses :
de cet article SQL Server 2008 Livres en ligne (octobre 2009) - Effectuer des asynchrones Opérations , je cite:
Traitement asynchrone permet méthodes pour revenir immédiatement sans blocage sur le fil d'appel. Cette permet une grande partie du pouvoir et flexibilité de multithreading, sans obliger le développeur à explicitement créer des fils ou une poignée synchronisation.
Si vous avez explicitement créé ces threads et géré la synchronisation, vous ne trouverez probablement pas beaucoup de différence.
Je pense qu'il veut dire «pourquoi utiliser un débutant des fournisseurs de données« Beginexecute ___ () / endexecute ____ () 'vs simplement les envelopper dans un délégué.
Si vous voulez dire "Pourquoi utiliser un fournisseur de données D'autres raisons possibles sont que cela correspond à la manière dont l'ancien code qu'ils aient été mis à jour ou d'emballage pour l'original .NET fonctionnent ou que les méthodes intégrées vous permettent de vérifier facilement toutes les exceptions restituées Beginexecute ___ () / endexecute ____ () Méthodes vs vs Juste enveloppant un EXECUTE ____ () Dans un délégué, je soupçonne la réponse Est-ce que quand ils ont d'abord conçu le modèle de fournisseur pour ADO.net pour .NET 1.0, enveloppant quelque chose dans un délégué et l'invoquant de manière asynchrone n'était pas si simple.
Peut-être que les MS Guys de leur équipe .NET connaissent mieux: P
SQLCLIENT'S BeginSecute / Endexecute Utilisez ASYNC IO Si la connexion est correctement configurée, elles ne sont pas simplement un délégué ordinaire ASYNC invoqué.
Le problème avec le traitement asynchrone .Net ( Avec des paires d'APM de début / Endaction, on peut invoquer la même action de manière non bloquante, et ce n'est que lorsque le résultat est renvoyé via un port d'achèvement de l'IO qu'il est mis en file d'attente en tant qu'élément de travail dans le threadpool. Aucun de vos discussions ne sont liés dans l'intervalle et, au point que la réponse à la file d'attente est traitée, les données sont disponibles dans le sens de l'utilisateur ne bloquent pas sur IO et peut être complétée rapidement ... une utilisation beaucoup plus efficace de la Threadpool qui échoue à beaucoup plus de demandes de clients sans frais d'un fil par opération exceptionnelle. begininvoke (...) ) est que tout cela se passe est de tourner un thread pour traiter le code de manière synchrone. Une requête de 5 minutes attachera un fil pendant 5 minutes, le blocage (c'est-à-dire ne rien faire pour environ 99% du temps) alors qu'un résultat est calculé à l'extrémité distante. Sous la souche (de nombreuses requêtes à la fois), cela épuira la threadpool, attachant toutes les filetages d'un état bloqué. La threadpool deviendra des demandes de travail insensibles et de nouvelles demandes de travail subira une grande latence attendant que le threadpool enfonge des fils supplémentaires. Ce n'est pas l'utilisation prévue de la threadpool, car elle est conçue avec l'attente que les tâches qu'il est demandé de terminer doivent être de courte durée et non bloquantes.
.NET BegkinVoke simplifie simplement l'exécution dans un fil différent. Cela sera toujours plus lent qu'un appel synchrone et consommer des ressources supplémentaires. La seule raison pour laquelle cela serait utilisé serait de libérer le contexte de l'appelant pour procéder à d'autres opérations (par exemple, renvoyer un résultat d'une demande HTTP au client).
Méthodes asynchrones SQLCLIENT, lorsque le AsynchronePrarocessing La propriété sur la connexion est définie sur True et les méthodes de Beginexecute de SQLCommand sont utilisées, sont vraiment asynchrones. La commande SQL est affichée sur le canal de communication réseau et l'achèvement est invoqué lorsque le résultat est renvoyé par le serveur.
d'un point de vue de fiabilité, cependant, aucune de ces méthodes n'est utile. Ils s'appuient tous les deux sur le processus client pour rester là-bas jusqu'à ce que l'appel soit terminé, sinon le serveur SQL verrait le client débrancher et abandonner le traitement, en roulant tout travail intermédiaire. Envisagez une application ASP qui a accepté une demande HTTP, a soumis un traitement de paiement «asynchrone» et renvoyé une réponse. Il n'y a pas de moyen de garantir que le travail soumis se produira réellement.
Pour les situations Lorsque le traitement nécessite des garanties de fiabilité de fiabilité, la solution est de la queue sur le serveur, de l'engager, puis de continuer, en s'appuyant sur les propres capacités de traitement asynchrones de SQL Server. Il s'agit d'une méthode qui garantit le traitement même sur la présence de déconnectes clients, du processus ASP 'Recyclage', de la mise en miroir de la mise en miroir SQL Server ou du clustering, la récupération de catastrophe matérielle, à peu près tout ce que vous pouvez jetez-le, car est une manière durable transactionnelle de soumettre Demandes de traitement asynchrones. Pour un exemple, voir Exécution de procédure asynchrone .
Comme mentionné dans les réponses antérieures, Le L'avantage de cette dernière approche est qu'il est beaucoup plus évolutif. Vous pouvez traiter des centaines ou des milliers de demandes simultanées de cette façon, où les frais généraux avec un fil-péral seraient extrêmes. De plus, vous consommeriez très rapidement l'ensemble du pool de fil ASP.NET (il n'a qu'un maximum d'environ 12 threads par défaut). begininvoke utilise un thread .net. Tout aussi important, cependant, est que le fil provient du pool de threads ASP.NET, il est donc en concurrence avec les clients pour les ressources de fil très limitées. Il en va de même pour threadpool.queueUserWorkItem () .
sqlclient ASYNC nécessite un sqlconnection qui a async = véritable activé. Ce mode nécessite un peu plus de surcharge de réseau (c'est pourquoi il n'est pas activé par défaut), mais cela ne consomme pas de fil de la piscine de fil .NET. Au lieu de cela, il utilise ASYNC E / S.