Vue d'ensemble de l'accès concurrentiel optimiste (LINQ to SQL)
Mise à jour : November 2007
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 d'accès concurrentiel |
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 d'accès 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. Effectuez une comparaison avec le contrôle d'accès concurrentiel pessimiste, qui verrouille l'enregistrement pour éviter les conflits d'accès concurrentiel. Le contrôle optimiste est appelé ainsi 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. Lorsqu'un objet est actualisé, le dispositif de suivi des modifications LINQ to SQL contient les données suivantes :
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 que LINQ to SQL découvre 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 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.
.gif "Remarque") Remarque : |
|---|
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 :
|
Manager |
Assistant |
Department |
|---|---|---|---|
État d'origine |
Alfreds |
Maria |
Sales |
User1 |
Alfred |
|
Marketing |
User2 |
|
Mary |
Service |
Vous pouvez résoudre des conflits comme celui-ci de différentes façons. Pour plus d'informations, consultez Procédure : gérer les conflits de changement (LINQ to SQL).
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 Procédure : spécifier les membres dont les conflits d'accès concurrentiel doivent être vérifiés (LINQ to SQL).
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 Procédure : spécifier le moment où des exceptions d'accès concurrentiel sont levées (LINQ to SQL).
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 Procédure : récupérer des informations sur les conflits entre entités (LINQ to SQL) et Procédure : récupérer des informations sur les conflits entre membres (LINQ to SQL).
Incluez dans votre code try/catch la façon dont vous souhaitez résoudre les différents conflits que vous découvrez.
Pour plus d'informations, consultez Procédure : résoudre des conflits d'accès concurrentiel en conservant des valeurs de base de données (LINQ to SQL), Procédure : résoudre des conflits d'accès concurrentiel en remplaçant des valeurs de base de données (LINQ to SQL) et Procédure : résoudre les conflits d'accès concurrentiel en fusionnant des valeurs de base de données (LINQ to SQL).
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 de conflits dans l'accès concurrentiel optimiste dans LINQ to SQL incluent les éléments suivants :