Gestion de l'accès concurrentiel aux données

Les Services RIA WCF prennent en charge l'accès concurrentiel optimiste afin de garantir la cohérence des données et comptent sur les développeurs pour fournir la logique de gestion des conflits potentiels pouvant survenir lors de la mise à jour d'une source de données. Si vous permettez aux utilisateurs de mettre à jour ou de supprimer des données, assurez-vous que les données dans la source de données n'ont pas été modifiées par un autre processus avant de mettre à jour ses valeurs dans l'enregistrement de données ou les supprimer dans l'enregistrement. Si vous ne vérifiez pas si les valeurs ont changé, vous risquez de remplacer involontairement des valeurs définies par un autre processus et de laisser les données dans un état incohérent. Pour l'accès concurrentiel optimiste, de tels conflits sont rares, mais il convient de comparer la valeur qu'il obtient de la source de données et qu'il est susceptible de changer ou de supprimer, avec la valeur figurant actuellement dans la source. Si ces valeurs ne correspondent pas, une OptimisticConcurrencyException devant être traitée est levée.

Pour connaître les procédures permettant de spécifier une vérification de la cohérence des valeurs, consultez Procédure : activer les contrôles d'accès concurrentiel optimiste. Pour plus d'informations sur l'utilisation de transactions explicites pour garantir la cohérence, consultez Procédure : Ajouter des transactions explicites à un service de domaine

Utilisation des attributs d'accès concurrentiel

Par défaut, les Services RIA ne transmettent pas l'intégralité de l'entité d'origine, avec les valeurs modifiées, à la couche d'accès aux données où vérifier l'accès concurrentiel aux données. Au lieu de cela, les Services RIA stockent et retransmettent uniquement les membres marqués avec l'attribut RoundtripOriginalAttribute, l'attribut ConcurrencyCheckAttribute ou l'attribut TimestampAttribute.

Chacun de ces attributs peut être appliqué aux propriétés dans une classe de métadonnées, ou à la classe de métadonnées proprement dite, lors de l'utilisation d'Entity Framework. Les attributs peuvent également être appliqués directement aux propriétés ou aux classes de types CLR lors de l'utilisation de modèles de données définies POCO. Pour plus d'informations, consultez Procédure : Ajouter des classes de métadonnées. Lorsque vous générez un projet après avoir appliqué ces attributs, ces derniers s'affichent sur le code généré client pour les propriétés ou les classes. Lorsqu'un attribut est appliqué à une classe et non à une propriété dans la classe, cela revient à appliquer l'attribut à l'ensemble des membres de la classe. Les attributs ConcurrencyCheckAttribute et TimestampAttribute peuvent également entraîner l'affichage de RoundtripOriginalAttribute sur la classe ou la propriété cliente à laquelle ils ont été appliqués dans les métadonnées du service de domaine. Cette implémentation permet d'optimiser les performances de votre application en spécifiant uniquement les membres qui doivent participer au contrôle d'accès concurrentiel. Pour plus d'informations, consultez

Remarque :

Si KeyAttribute est appliqué à la propriété d'un type d'entité, cette opération ajoute également RoundtripOriginalAttribute à la propriété correspondante générée sur le client lors de la génération du projet. Par conséquent, dans les services de domaine générés à partir d'une source de base de données avec l'assistant Ajouter une nouvelle classe de service de domaine, il s'agit du comportement par défaut pour les propriétés faisant office de clé d'entité.

Lorsque RoundtripOriginalAttribute est appliqué, la couche d'accès aux données compare la valeur d'origine dans la source de données recodée au moment de la récupération des données avec la valeur actuelle des données dans la source de données. Si les valeurs sont identiques, les données dans le magasin n'ont pas été modifiées et la couche d'accès aux données met à jour ou supprime les données. Si les données ont changé, un conflit se produit et une OptimisticConcurrencyException est levée. Des informations sur le conflit sont stockées dans la propriété EntityConflict de l'entité dont les données ne sont plus à jour.

Si vous appliquez l'attribut ExcludeAttribute à un membre dans une entité qui peut être mise à jour ou supprimée à partir du client, ce membre ne peut pas être utilisé pour des contrôles d'accès concurrentiel optimiste. Lorsque vous excluez le membre, la valeur d'origine correcte n'est pas stockée pour ce membre et l'opération de mise à jour échoue toujours. Pour plus d'informations, consultez Procédure : Ajouter des classes de métadonnées.

Gestion d'OptimisticConcurrencyException

Lorsque les modifications apportées aux données dans le cache de l'objet sont en conflit avec les modifications effectuées dans la source de données une fois que les objets ont été ajoutés au cache ou actualisés dans le cache, la transaction entière est restaurée. Lorsqu'une OptimisticConcurrencyException se produit, vous devez la traiter en précisant si le conflit doit être résolu en préservant les données dans les données d'objet (ClientWins) ou en mettant à jour le cache d'objet avec les données de la source de données (StoreWins). Pour obtenir de l'aide sur cette opération, consultez Enregistrement des modifications et gestion de l'accès concurrentiel