Författarewww.itsvse.com @小渣渣 !
Sätt in basdatan framgångsrikt!
Testningen av ConcurrencyCheck-funktionen är klar
Uppdateringen lyckades! Not 1
Uppdateringen är exceptionell! Not 2, onormal information! Store-update, insert- eller delete-satsen påverkade ett oväntat antal rader (0). Entiteter kan ha modifierats eller tagits bort sedan entiteter laddades. Se http://go.microsoft.com/fwlink/?LinkId=472540 för information om hur man kan förstå och hantera undantag för optimistiska samtidighet.
Testa skillnaden mellan Timestamp och ConcurrencyCheck
Uppdatering av Tab1 lyckades! Namn 1
UpdateTab2-uppdateringen lyckades! Namn 1
UpdateTab2-uppdateringen är onormal! Namn 2, onormal information! Store-update, insert- eller delete-satsen påverkade ett oväntat antal rader (0). Entiteter kan ha modifierats eller tagits bort sedan entiteter laddades. Se http://go.microsoft.com/fwlink/?LinkId=472540 för information om hur man kan förstå och hantera undantag för optimistiska samtidighet.
Uppdatering av Tab1 lyckades! Namn 2
【TimeStamp】
Funktionen TimeStamp kan appliceras på fältklassen, som endast har en bytearrayegenskap, och denna funktion sätter tiemStamp-typen till kolumnen. Vid samtidiga kontroller använder Code-First automatiskt detta fält av TimeStamp-typ.
【ConcurrencyCheck】
ConcurrencyCheck-funktionen kan tillämpas på egenskaperna hos en domänklass. När EF utför en uppdateringsoperation lägger Code-First värdet på kolumnen i where-villkoret, och du kan använda denna CurrencyCheck-funktion för att använda befintliga kolumner för samtidighetskontroll, istället för att använda en separat TimeStamp-kolumn för samtidighetskontroll.
Låt oss börja med att skapa ett nytt kontextobjekt för att visa skillnaden mellan Timestamp och ConcurrencyCheck vid samtidighetsbehandling!
Här är koden för sammanhanget:
Låt oss titta på kolumnerna i databasen, enligt följande:
Vi kommer att upptäcka att flik 1 och flik 2 har kolumnerna Id, Namn och Kommentar, och flik 2 har fler kolumner i RowVersion än flik 1.
Bifoga testkoden först:
【ConcurrencyCheck Principle】
Vi lade till ConcurrencyCheck-funktionen i Remark-egenskapen i Tab1,
När vi uppdaterar Namn-attributvärdet för samma data samtidigt kastas inget undantag!
Generera SQL-satser:
exec sp_executesql N'UPDATE [dbo]. [Tab1]
SET [Namn] = @0
DÄR (([id] = @1) OCH ([Anmärkning] = @2))
',N'@0 nvarchar(max) ,@1 int,@2 nvarchar(max) ',@0=N'name1',@1=1,@2=N'Note1' exec sp_executesql N'UPDATE [dbo]. [Tab1]
SET [Namn] = @0
DÄR (([id] = @1) OCH ([Anmärkning] = @2))
',N'@0 nvarchar(max) ,@1 int,@2 nvarchar(max) ',@0=N'name2',@1=1,@2=N'note1'
När vi uppdaterar Remark-egenskapsvärdet för samma data samtidigt, kastar vi ett undantag!
Generera SQL-satser:
exec sp_executesql N'UPDATE [dbo]. [Tab1]
SET [Anmärkning] = @0
DÄR (([id] = @1) OCH ([Anmärkning] = @2))
',N'@0 nvarchar(max) ,@1 int,@2 nvarchar(max) ',@0=N'Note1',@1=1,@2=N'Note' exec sp_executesql N'UPDATE [dbo]. [Tab1]
SET [Anmärkning] = @0
DÄR (([id] = @1) OCH ([Anmärkning] = @2))
',N'@0 nvarchar(max) ,@1 int,@2 nvarchar(max) ',@0=N'Note 2',@1=1,@2=N'Note'
Vi kan se att om vi tar samma databit med ID 1 samtidigt, får vi värdet av Remark-attributet, och när vi uppdaterar Remark-attributet använder vi Remark som uppdateringsvillkor.
Den första SQL-satsen kan uppdateras framgångsrikt, och sedan ändras kommentaren till "note 1", och när den andra SQL-satsen uppdateras kommer uppdateringen att misslyckas eftersom värdet på kommentaren har ändrats.
【Tidsstämpelprincipen】
Vi lade till en egenskap RowVersion i Tab2 (du kan ta vilket namn som helst) och lade till funktionen Timestamp!!
När vi uppdaterar Namnvärdet för samma data samtidigt, lyckas den första uppdateringen, den andra misslyckas och ett undantag kastas, låt oss titta på den genererade SQL-koden!
exec sp_executesql N'UPDATE [dbo]. [Tab2]
SET [Namn] = @0
DÄR ((([Id] = @1) OCH ([RowVersion] = @2)) OCH ([Anmärkning] = @3))
VÄLJ [RadVersion]
FRÅN [dbo]. [Tab2]
DÄR @@ROWCOUNT > 0 OCH [id] = @1',N'@0 nvarchar(max) ,@1 int,@2 binär(8),@3 nvarchar(max) ',@0=N'Namn1',@1=1,@2=0x00000000000007D1,@3=N'Note' exec sp_executesql N'UPDATE [dbo]. [Tab2]
SET [Namn] = @0
DÄR ((([Id] = @1) OCH ([RowVersion] = @2)) OCH ([Anmärkning] = @3))
VÄLJ [RadVersion]
FRÅN [dbo]. [Tab2]
DÄR @@ROWCOUNT > 0 OCH [id] = @1',N'@0 nvarchar(max) ,@1 int,@2 binär(8),@3 nvarchar(max) ',@0=N'name2',@1=1,@2=0x00000000000007D1,@3=N'Note'
När den andra SQL-satsen körs, eftersom datan för where-villkoret inte längre kan hittas, misslyckas uppdateringen och ett undantag kastas!!
Efter att den första SQL-satsen har körts framgångsrikt kommer värdet på RowVersion att ändras, som visas i figuren nedan:
RowsVersion är tidsstämpel
En lösning på saknade uppdateringar
Konceptet med saknade uppdateringar: När användare ändrar en datarad samtidigt läser de först datan, lägger den på frontend för ändring och skickar sedan in datan när den ändras, så att den slutliga inskickade datan skriver över den tidigare inskickade datan, vilket leder till den förlorade uppdateringen.
Kort sagt, här är sätt att undvika att förlora uppdateringar:
Använd tidsstämpeln RowsVersion.
Om en rad är inkonsekvent med värdet före läsning betyder det att en annan transaktion har uppdaterat denna kolumn, så att denna kolumn inte kan uppdateras, vilket förhindrar förlust av uppdateringar.
Slutligen, bifoga källkoden:
CodeFirstDemo.rar
(4.94 KB, Antal nedladdningar: 13)
|
Publicerad på 2017-04-08 00:10:50
|
|
|
|
Publicerad på 2022-03-22 11:51:38
|
Hyresvärd|
Publicerad på 2023-11-01 20:42:15
|
