Auteurwww.itsvse.com @小渣渣 ! Insérez les données de base avec succès ! Le test de la fonctionnalité ConcurrencyCheck est terminé Mise à jour réussie ! Note 1 La mise à jour est exceptionnelle ! Note 2, informations anormales ! L’instruction mise à jour, insertion ou suppression du magasin affectait un nombre inattendu de lignes (0). Les entités peuvent avoir été modifiées ou supprimées depuis leur chargement. Voir http://go.microsoft.com/fwlink/?LinkId=472540 pour des informations sur la compréhension et la gestion des exceptions de concurrence optimiste.
Testez la différence entre Timestamp et ConcurrencyCheck Mise à jour UpdateTab1 réussie ! Nom 1 Mise à jour UpdateTab2 réussie ! Nom 1 Mise à jour de l’onglet 2 est anormale ! Nomme-en deux, informations anormales ! L’instruction mise à jour, insertion ou suppression du magasin affectait un nombre inattendu de lignes (0). Les entités peuvent avoir été modifiées ou supprimées depuis leur chargement. Voir http://go.microsoft.com/fwlink/?LinkId=472540 pour des informations sur la compréhension et la gestion des exceptions de concurrence optimiste. Mise à jour UpdateTab1 réussie ! Nom 2
【TimeStamp】 La fonction TimeStamp peut être appliquée à la classe champ, qui ne possède qu’une seule propriété de tableau d’octets, et cette fonctionnalité définit le type tiemStamp sur la colonne. Dans les vérifications simultanées, Code-First utilise automatiquement ce champ de type TimeStamp.
【Chèque de concurrence】 La fonctionnalité ConcurrencyCheck peut être appliquée aux propriétés d’une classe de domaine. Lorsque EF effectue une opération de mise à jour, Code-First place la valeur de la colonne dans l’instruction condition where, et vous pouvez utiliser cette fonctionnalité CurrencyCheck pour utiliser les colonnes existantes pour la vérification de la concurrence, plutôt que d’utiliser une colonne TimeStamp séparée pour la vérification de la concurrence.
Commençons par créer un nouvel objet de contexte pour démontrer la différence entre Timestamp et Concurrency Check dans le traitement de la concurrence concurrente !
Voici le code pour le contexte :
Jetons un œil aux colonnes de la base de données, comme suit :
Nous constaterons que tab1 et tab2 ont des colonnes Id, Nom et Remark, et que tab2 a plus de colonnes RowVersion que tab1.
Ajoutez d’abord le code de test :
【Principe de contrôle de concurrence】
Nous avons ajouté la fonctionnalité ConcurrencyCheck à la propriété Remark de Tab1,
Lorsque nous mettons à jour la valeur de l’attribut Nom des mêmes données en même temps, aucune exception n’est lancée !
Générer des instructions SQL :
exécutif sp_executesql N’UPDATE [dbo]. [Tab1] SET [Nom] = @0 OÙ (([Id] = @1) ET ([Remarque] = @2)) ',N'@0 nvarchar(max) ,@1 int,@2 nvarchar(max) ',@0=N’name1',@1=1,@2=N’Note1' exécutif sp_executesql N’UPDATE [dbo]. [Tab1] SET [Nom] = @0 OÙ (([Id] = @1) ET ([Remarque] = @2)) ',N'@0 nvarchar(max) ,@1 int,@2 nvarchar(max) ',@0=N’name2',@1=1,@2=N’note1' Lorsque nous mettons à jour la valeur de la propriété Remark des mêmes données en même temps, nous lançons une exception !
Générer des instructions SQL :
exécutif sp_executesql N’UPDATE [dbo]. [Tab1] SET [Remarque] = @0 OÙ (([Id] = @1) ET ([Remarque] = @2)) ',N'@0 nvarchar(max) ,@1 int,@2 nvarchar(max) ',@0=N’Note1',@1=1,@2=N’Note' exécutif sp_executesql N’UPDATE [dbo]. [Tab1] SET [Remarque] = @0 OÙ (([Id] = @1) ET ([Remarque] = @2)) ',N'@0 nvarchar(max) ,@1 int,@2 nvarchar(max) ',@0=N’Note 2',@1=1,@2=N’Note' Nous pouvons constater que si nous prenons la même donnée avec Id 1 en même temps, nous obtiendrons la valeur de l’attribut Remark, et lors de la mise à jour de l’attribut Remark, nous utiliserons Remark comme condition de mise à jour.
La première instruction sql peut être mise à jour avec succès, puis la remarque est changée en « note 1 », et lorsque la deuxième instruction sql est mise à jour, la mise à jour échoue car la valeur de la remarque a changé.
【Principe d’horodatage】
Nous avons ajouté une propriété RowVersion à Tab2 (vous pouvez prendre n’importe quel nom) et ajouté la fonction Timestamp !!
Lorsque nous mettons à jour la valeur Name des mêmes données en même temps, la première mise à jour réussit, la seconde échoue, et une exception est lancée, regardons le code SQL généré !
exécutif sp_executesql N’UPDATE [dbo]. [Tab2] SET [Nom] = @0 OÙ ((([Id] = @1) ET ([RowVersion] = @2)) ET ([Remarque] = @3)) SELECT [RowVersion] DE [dbo]. [Tab2] OÙ @@ROWCOUNT > 0 ET [Id] = @1',N'@0 nvarchar(max) ,@1 int,@2 binary(8),@3 nvarchar(max) ',@0=N’Name1',@1=1,@2=0x00000000000007D1,@3=N’Note' exécutif sp_executesql N’UPDATE [dbo]. [Tab2] SET [Nom] = @0 OÙ ((([Id] = @1) ET ([RowVersion] = @2)) ET ([Remarque] = @3)) SELECT [RowVersion] DE [dbo]. [Tab2] OÙ @@ROWCOUNT > 0 ET [Id] = @1',N'@0 nvarchar(max) ,@1 int,@2 binary(8),@3 nvarchar(max) ',@0=N’name2',@1=1,@2=0x00000000000007D1,@3=N’Note' Lors de l’exécution de la deuxième instruction SQL, comme les données de la condition where ne sont plus disponibles, la mise à jour échoue et une exception est lancée !!
Après l’exécution réussie de la première instruction sql, la valeur de RowVersion changera, comme montré dans la figure ci-dessous :
RowsVersion est un horodatage
Solution de contournement pour les mises à jour manquantes
Concept de mises à jour manquantes : Lorsque les utilisateurs modifient une ligne de données en même temps, ils lisent d’abord les données, les mettent en interface pour modification, puis soumettent les données lors de la modification, afin que les données finales soumises écrasent les données précédemment soumises, ce qui provoque la mise à jour perdue.
Pour faire court, voici des moyens d’éviter de perdre des mises à jour :
Utilisez l’horodatage RowsVersion.
Si une ligne est incohérente avec la valeur avant lecture, cela signifie qu’une autre transaction a mis à jour cette colonne, de sorte que cette colonne ne peut pas être mise à jour, évitant ainsi la perte des mises à jour.
Enfin, joignez le code source :
CodeFirstDemo.rar
(4.94 KB, Nombre de téléchargements: 13)
|