Forfatterwww.itsvse.com @小渣渣 !
Indsæt basisdataene med succes!
Test af ConcurrencyCheck-funktionen er færdig
Opdatering lykkedes! Note 1
Opdateringen er enestående! Note 2, unormal information! Storeopdatering, indsæt eller delete-sætningen påvirkede et uventet antal rækker (0). Entiteter kan være blevet ændret eller slettet, siden entiteterne blev indlæst. Se http://go.microsoft.com/fwlink/?LinkId=472540 for information om forståelse og håndtering af optimistiske samtidighedsundtagelser.
Test forskellen mellem Timestamp og ConcurrencyCheck
Opdatering Tab1 er succesfuld! Navn 1
Opdatering Tab2 er succesfuld! Navn 1
UpdateTab2-opdateringen er unormal! Navn 2, unormal information! Storeopdatering, indsæt eller delete-sætningen påvirkede et uventet antal rækker (0). Entiteter kan være blevet ændret eller slettet, siden entiteterne blev indlæst. Se http://go.microsoft.com/fwlink/?LinkId=472540 for information om forståelse og håndtering af optimistiske samtidighedsundtagelser.
Opdatering Tab1 er succesfuld! Navn 2
【TimeStamp】
TimeStamp-funktionen kan anvendes på feltklassen, som kun har én byte-array-egenskab, og denne funktion sætter tiemStamp-typen til kolonnen. Ved samtidige kontroller bruger Code-First automatisk dette TimeStamp-type felt.
【ConcurrencyCheck】
ConcurrencyCheck-funktionen kan anvendes på egenskaberne for en domæneklasse. Når EF udfører en opdateringsoperation, sætter Code-First værdien af kolonnen i where-betingelsessætningen, og du kan bruge denne CurrencyCheck-funktion til at bruge de eksisterende kolonner til samtidighedskontrol i stedet for at bruge en separat TimeStamp-kolonne til samtidighedskontrol.
Lad os starte med at oprette et nyt kontekstobjekt for at demonstrere forskellen mellem Timestamp og ConcurrencyCheck i samtidighedsbehandling!
Her er koden for konteksten:
Lad os se på kolonnerne i databasen som følger:
Vi vil opdage, at fane-1 og fane-2 har Id-, Navn- og Bemærk-kolonnerne, og fane-2 har flere RowVersion-kolonner end fane 1.
Vedhæft testkoden først:
【ConcurrencyCheck Principle】
Vi tilføjede ConcurrencyCheck-funktionen til Remark-egenskaben i Tab1,
Når vi opdaterer Navn-attributværdien for de samme data på samme tid, kastes ingen undtagelse!
Generer SQL-sætninger:
exec sp_executesql N'UPDATE [dbo]. [Tab1]
SÆT [Navn] = @0
HVOR (([id] = @1) OG ([Bemærk] = @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]
SÆT [Navn] = @0
HVOR (([id] = @1) OG ([Bemærk] = @2))
',N'@0 nvarchar(max) ,@1 int,@2 nvarchar(max) ',@0=N'name2',@1=1,@2=N'note1'
Når vi opdaterer Remark-egenskabsværdien for de samme data på samme tid, kaster vi en undtagelse!
Generer SQL-sætninger:
exec sp_executesql N'UPDATE [dbo]. [Tab1]
SÆT [Bemærk] = @0
HVOR (([id] = @1) OG ([Bemærk] = @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]
SÆT [Bemærk] = @0
HVOR (([id] = @1) OG ([Bemærk] = @2))
',N'@0 nvarchar(max) ,@1 int,@2 nvarchar(max) ',@0=N'Note 2',@1=1,@2=N'Note'
Vi kan finde, at hvis vi tager det samme stykke data med ID 1 på samme tid, får vi værdien af Remark-attributtet, og når vi opdaterer Remark-attributtet, vil vi bruge Remark som opdateringsbetingelse.
Den første SQL-sætning kan opdateres med succes, og derefter ændres kommentaren til "note 1", og når den anden SQL-sætning opdateres, vil opdateringen fejle, fordi værdien af kommentaren har ændret sig.
【Tidsstempelprincippet】
Vi tilføjede en RowVersion-egenskab til Tab2 (du kan tage et hvilket som helst navn) og tilføjede Timestamp-funktionen!!
Når vi opdaterer Navneværdien for de samme data på samme tid, lykkes den første opdatering, den anden opdatering fejler, og en undtagelse kastes – lad os se på den genererede SQL-kode!
exec sp_executesql N'UPDATE [dbo]. [Tab2]
SÆT [Navn] = @0
HVOR ((([Id] = @1) OG ([RowVersion] = @2)) OG ([Bemærk] = @3))
VÆLG [RækkeVersion]
FRA [dbo]. [Tab2]
HVOR @@ROWCOUNT > 0 OG [id] = @1',N'@0 nvarchar(max) ,@1 int,@2 binær(8),@3 nvarchar(max) ',@0=N'Navn1',@1=1,@2=0x00000000000007D1,@3=N'Note' exec sp_executesql N'UPDATE [dbo]. [Tab2]
SÆT [Navn] = @0
HVOR ((([Id] = @1) OG ([RowVersion] = @2)) OG ([Bemærk] = @3))
VÆLG [RækkeVersion]
FRA [dbo]. [Tab2]
HVOR @@ROWCOUNT > 0 OG [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 man udfører den anden SQL-sætning, fordi dataene fra where-betingelsen ikke længere kan findes, fejler opdateringen, og en undtagelse kastes!!
Efter at den første SQL-sætning er udført med succes, vil værdien af RowVersion ændre sig, som vist i figuren nedenfor:
RowsVersion er tidsstempel
En løsning på manglende opdateringer
Konceptet med manglende opdateringer: Når brugere ændrer en linje med data samtidig, læser de først dataene, lægger dem på frontenden til ændring og indsender derefter dataene, når de er ændret, så de endelige indsendte data overskriver de tidligere indsendte data, hvilket forårsager tabt opdatering.
Lang historie kort, her er måder at undgå at miste opdateringer på:
Brug tidsstemplet RowsVersion.
Hvis en række er inkonsistent med værdien før læsning, betyder det, at en anden transaktion har opdateret denne kolonne, så denne kolonne ikke kan opdateres, og dermed forhindres tab af opdateringer.
Endelig vedhæft kildekoden:
CodeFirstDemo.rar
(4.94 KB, Antal downloads: 13)
|
Opslået på 08/04/2017 00.10.50
|
|
|
|
Opslået på 22/03/2022 11.51.38
|
Udlejer|
Opslået på 01/11/2023 20.42.15
|
