Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
LINQ to SQL prend en charge la gestion de la concurrence optimiste. Le tableau suivant décrit les termes qui s’appliquent à la concurrence optimiste dans la documentation LINQ to SQL :
| Termes | Descriptif |
|---|---|
| accès concurrentiel | Situation dans laquelle deux utilisateurs ou plus essaient simultanément de mettre à jour la même ligne de base de données. |
| conflit de concurrence | Situation dans laquelle deux utilisateurs ou plusieurs utilisateurs essaient simultanément d’envoyer des valeurs en conflit à une ou plusieurs colonnes d’une ligne. |
| Contrôle de concurrence | Technique utilisée pour résoudre les conflits d’accès concurrentiel. |
| contrôle concurrentiel optimiste | Technique qui examine d’abord si d’autres transactions ont modifié des valeurs dans une ligne avant d’autoriser la soumission des modifications. Par opposition au contrôle d’accès concurrentiel pessimiste, qui verrouille l’enregistrement pour éviter les conflits d’accès concurrentiel. Le contrôle optimiste est ainsi appelé parce qu’il considère que les chances qu'une transaction interfère avec une autre sont peu probables. |
| résolution de conflit | Processus d’actualisation d’un élément en conflit en interrogeant à nouveau la base de données, puis en réconciliant les différences. Lorsqu’un objet est actualisé, le suivi des modifications LINQ to SQL contient les données suivantes : - Valeurs initialement extraites de la base de données et utilisées pour la vérification de mise à jour. - Nouvelles valeurs de base de données de la requête suivante. LINQ to SQL détermine ensuite si l’objet est en conflit (autrement dit, si une ou plusieurs de ses valeurs membres ont changé). Si l’objet est en conflit, LINQ to SQL détermine ensuite quels membres sont en conflit. Tout conflit de membre détecté par LINQ to SQL est ajouté à une liste de conflits. |
Dans le modèle objet LINQ to SQL, un conflit d’accès concurrentiel optimiste se produit lorsque les deux conditions suivantes sont remplies :
Le client tente d’envoyer des modifications à la base de données.
Une ou plusieurs valeurs de vérification des mises à jour ont été mises à jour dans la base de données depuis la dernière lecture du client.
La résolution de ce conflit inclut la découverte des membres de l’objet en conflit, puis la décision de ce que vous voulez faire à ce sujet.
Remarque
Seuls les membres mappés en tant que Always ou WhenChanged participent aux vérifications de concurrence optimiste. Aucune vérification n’est effectuée pour les membres marqués Never. Pour plus d’informations, consultez UpdateCheck.
Exemple :
Par exemple, dans le scénario suivant, User1 commence à préparer une mise à jour en interrogeant la base de données pour une ligne. User1 reçoit une ligne avec les valeurs d’Alfreds, Maria et Sales.
User1 souhaite modifier la valeur de la colonne Gestionnaire sur Alfred et la valeur de la colonne Department sur Marketing. Avant que User1 puisse soumettre ces modifications, User2 a soumis des modifications à la base de données. Désormais, la valeur de la colonne Assistant a donc été modifiée en Mary et la valeur de la colonne Department en Service.
Lorsque User1 tente maintenant d’envoyer des modifications, la soumission échoue et une ChangeConflictException exception est lancée. Ce résultat se produit parce que les valeurs de base de données de la colonne Assistant et de la colonne Department ne sont pas celles attendues. Les membres représentant les colonnes Assistant et Département sont en conflit. Le tableau suivant récapitule la situation.
| État | Gestionnaire | Assistant(e) | Département |
|---|---|---|---|
| État d’origine | Alfreds | Maria | Ventes |
| Utilisateur1 | Alfred | Commercialisation | |
| Utilisateur2 | Marie | Service |
Vous pouvez résoudre des conflits tels que ceux-ci de différentes manières. Pour plus d’informations, consultez Guide pratique pour gérer les conflits de modification.
Liste de contrôle de détection et de résolution des conflits
Vous pouvez détecter et résoudre les conflits à n’importe quel niveau de détail. À un extrême, vous pouvez résoudre tous les conflits de l’une des trois manières (voir RefreshMode) sans considération supplémentaire. À l’autre extrême, vous pouvez désigner une action spécifique pour chaque type de conflit sur chaque membre en conflit.
Spécifiez ou modifiez les options UpdateCheck dans votre modèle objet.
Pour plus d’informations, consultez Guide pratique pour spécifier les membres dont les conflits d’accès concurrentiel sont testés.
Dans le bloc try/catch de votre appel à SubmitChanges, spécifiez à quel point vous souhaitez que les exceptions soient levées.
Pour plus d’informations, consultez Comment : Spécifier Quand les Exceptions de Concurrence sont Levées.
Déterminez la quantité de détails de conflit que vous souhaitez récupérer et incluez du code dans votre bloc try/catch en conséquence.
Pour plus d’informations, consultez Comment : Récupérer les informations de conflit d'entité et Comment : Récupérer les informations de conflit de membre.
Incluez dans votre
try/catchcode la façon dont vous souhaitez résoudre les différents conflits que vous découvrez.Pour plus d’informations, consultez Guide pratique pour résoudre les conflits en conservant les valeurs de base de données, comment : résoudre les conflits en remplaçant les valeurs de base de données et comment : résoudre les conflits en fusionnant avec des valeurs de base de données.
Types LINQ to SQL qui prennent en charge la découverte et la résolution des conflits
Les classes et fonctionnalités permettant de prendre en charge la résolution des conflits dans la concurrence optimiste avec LINQ to SQL sont les suivantes :