Accès concurrentiel optimiste : Vue d'ensemble
LINQ to SQL prend en charge le contrôle d’accès concurrentiel optimiste. Le tableau suivant décrit les termes applicables à l’accès concurrentiel optimiste dans la documentation de LINQ to SQL :
| Termes | Description |
|---|---|
| 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 plus essaient simultanément de soumettre des valeurs incompatibles à une ou plusieurs colonnes d'une ligne. |
| contrôle d'accès concurrentiel | Technique utilisée pour résoudre des conflits d'accès concurrentiel. |
| contrôle concurrentiel optimiste | Technique qui recherche d’abord si d’autres transactions ont modifié les valeurs d’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é car il considère que les risques qu’une transaction interfère avec une autre sont faibles. |
| résolution de conflit | Processus d'actualisation d'un élément en conflit en interrogeant de nouveau la base de données, puis en harmonisant les différences. Quand un objet est actualisé, le dispositif de suivi des modifications de LINQ to SQL contient les données suivantes : - Les valeurs provenant initialement de la base de données et utilisées pour la vérification des mises à jour. - Les nouvelles valeurs de la base de données provenant de la requête qui s’ensuit. LINQ to SQL détermine ensuite si l’objet est en conflit (c’est-à-dire si une ou plusieurs de ses valeurs membres ont été modifiées). Si l’objet est en conflit, LINQ to SQL détermine ensuite lesquels de ses membres sont en conflit. Tout conflit entre membres découvert 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 quand les deux conditions suivantes sont vraies :
Le client tente de soumettre des modifications à la base de données.
Une ou plusieurs valeurs de vérification de mise à jour ont été mises à jour dans la base de données depuis la dernière fois que le client les a lues.
La résolution de ce conflit inclut la découverte des membres de l'objet qui sont en conflit, puis la décision relative à l'action que vous souhaitez effectuer.
Notes
Seuls les membres mappés comme Always ou WhenChanged participent aux contrôles d'accès concurrentiel optimiste. Aucun contrôle n'est effectué 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 Alfreds, Maria et Sales.
User1 souhaite modifier la valeur de la colonne Manager en Alfred et la valeur de la colonne Department en 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 à présent de soumettre des modifications, la soumission échoue et une exception ChangeConflictException est levée. Ce résultat se produit car les valeurs de base de données des colonnes Assistant et Department ne sont pas celles qui étaient attendues. Les membres représentant les colonnes Assistant et Department sont en conflit. Le tableau suivant récapitule la situation :
| État | Manager | Assistant | department |
|---|---|---|---|
| État d'origine | Alfreds | Maria | Sales |
| Utilisateur1 | Alfred | Marketing | |
| User2 | Mary | Service |
Vous pouvez résoudre des conflits comme celui-ci de différentes façons. Pour plus d’informations, consultez Guide pratique pour gérer les conflits des modifications.
Détection de conflit et liste de vérification de résolution
Vous pouvez détecter et résoudre des conflits à n'importe quel niveau de détail. Une approche consiste à résoudre tous les conflits à l'aide d'une des trois façons (consultez RefreshMode) sans considération supplémentaire. Une autre approche consiste à désigner une action spécifique pour chaque type de conflit sur tous les membres en conflit.
Spécifiez ou modifiez des 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 Guide pratique pour spécifier quand des exceptions d’accès concurrentiel sont levées.
Déterminez la quantité de détails du conflit que vous souhaitez récupérer et incluez le code dans votre bloc try/catch en conséquence.
Pour plus d’informations, consultez Guide pratique pour récupérer des informations sur les conflits d’entités et Guide pratique pour récupérer des informations sur les conflits de membres.
Incluez dans votre code
try/catchcomment vous voulez 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 la base de données, Guide pratique pour résoudre les conflits en remplaçant les valeurs de la base de données et Guide pratique pour résoudre les conflits en fusionnant avec des valeurs de la base de données.
Types LINQ to SQL qui prennent en charge la découverte et la résolution de conflits
Les classes et les fonctionnalités pour prendre en charge la résolution des conflits dans l’accès concurrentiel optimiste dans LINQ to SQL incluent les éléments suivants :