> Tech > Notification de dépendance dans SQL Server 2005

Notification de dépendance dans SQL Server 2005

Tech - Par iTPro - Publié le 24 juin 2010
email

Le second modèle pour configurer les dépendances SQL Server 2005 repose sur les notifications. Lorsque je vois le terme notification associé à SQL Server 2005, je pense immédiatement à SQL Server Notification Services, mais il fait ici référence aux notifications de changements internes du SGBDR. Lorsqu’ASP.NET exécute une commande sur

Notification de dépendance dans SQL Server 2005

SQL Server 2005, il peut s’enregistrer pour toute modification liée à cette commande. Ces notifications sont comme des transactions automatiques dans le sens où vous démarrez le processus d’écoute les concernant en appelant la méthode System.Data.SqlClient. SqlDependency.Start().

Comme ASP.NET est un environnement multi-thread qui appelle des pages individuelles de manière répétée, vous pouvez placer cette déclaration à un seul emplacement, la méthode Application.Start de la page Global.ASAX de votre application. Celle-ci exécute le code dans ce fichier sur la base des événements de l’application, par exemple son démarrage. Lorsque vous demandez à ASP.NET et, indirectement, à ADO.NET de surveiller les notifications de modification de SQL Server, vous pouvez commencer à créer des dépendances. Dans ce cas, les dépendances référencent un gestionnaire de dépendances générique nommé notification de commande. Pour référencer ce gestionnaire, dans une déclaration de cache ou en tant que partie d’un objet SQLData- Source, ajoutez simplement la propriété suivante à votre attribut : SqlCacheDependency= "CommandNotification" Vous noterez qu’aucun nom de table n’est associé à cet enregistrement. Vous n’avez également besoin d’aucune entrée dans votre fichier web.config, ni de méthode aspnet_table ou access personnalisée. Toutefois, cette approche impose d’autres exigences.

Premièrement, vous devez octroyer au compte utilisé pour accéder à la base de données l’autorisation d’abonnement aux notifications de requête et d’envoi de celles-ci dans SQL Server. Vous octroyez les autorisations au moyen des commandes T-SQL du listing 4. Il est inutile d’exécuter ces commandes si vous employez le compte sa dans votre environnement de développement. Toutefois, dans un environnement de production, où vous appliquez les règles de sécurité recommandées et employez un compte ayant un niveau d’autorisation plus restreint, il faut exécuter ces commandes afin que votre utilisateur de base de données puisse tirer parti des informations de notification de requête. Lorsque le compte est autorisé à suivre les informations de notification de requête, il existe deux limitations principales qui réduisent les changements qu’il pourra détecter.

Mais commençons par examiner le type d’éléments faisant l’objet du suivi. Dans un objet DataSource ou Cache, vous exécutez des requêtes pour remplir les données mises en cache. A mesure que ces requêtes sont exécutées et que les données s’accumulent, ASP.NET effectue le suivi des requêtes employées. Il enregistre les résultats des requêtes dans SQL Server, puis à mesure que d’autres instructions sont exécutées, SQL Server détermine si les résultats des requêtes qui vous intéressent ont changé. Lorsque SQL Server détecte un changement qui affecte une de ces requêtes de base de données enregistrées, il envoie une notification à ASP.NET, lequel peut déclencher l’invalidation de l’objet Cache associé à la requête en question. La bonne nouvelle est que ce processus est entièrement automatique, autrement dit il est inutile de faire quoi que ce soit pour en retirer le bénéfice.

En revanche, quel est le nombre de requêtes pour lequel votre application ASP.NET peut être enregistrée ? C’est à ce stade qu’interviennent les deux limitations mentionnées précédemment. Pour les débutants, toute requête qui utilise un caractère générique (*) pour récupérer tous les champs d’une table (ce qui n’est en soi pas très élégant) est considérée systématiquement comme non valide. Il est impossible de s’enregistrer pour la notification des modifications sur cette table et vous allez récupérer les données avec chaque requête, éliminant ainsi la mise en cache.

La deuxième limitation est la suivante : pour l’enregistrement concernant une requête, vous devez employer le nom complet de propriétaire de la table figurant dans l’instruction SELECT, laquelle peut être incorporée dans une procédure stockée. Ainsi, pour l’exemple ci-dessus, votre requête devra référencer dbo.orders et non seulement orders. Pour plus d’informations sur les limitations potentielles des notifications de requêtes, consultez la rubrique « Using Query Notifications » dans la documentation en ligne SQL Server 2005 ou l’article MSDN « Creating a Query for Notification », à l’adresse http://msdn2.microsoft.com/enus/ library/ms181122.aspx.

Téléchargez gratuitement cette ressource

Guide de Services Cloud Managés

Guide de Services Cloud Managés

Accélérer votre transformation digitale, protéger et sécuriser vos environnements Cloud avec les offres de support, d'accompagnement et de services managés. Découvrez le TOP 3 des Services Managés pour accompagner la transformation de vos environnements Cloud, gagner en agilité et en sécurité dans un monde d'incertitudes.

Tech - Par iTPro - Publié le 24 juin 2010