Kirjailijawww.itsvse.com @小渣渣 !
Syötä perustiedot onnistuneesti!
ConcurrencyCheck-ominaisuuden testaus on valmis
Päivitys onnistui! Huomautus 1
Päivitys on erinomainen! Huomautus 2, epänormaalia tietoa! Store update, insert or delete -lause vaikutti odottamattomaan määrään rivejä (0). Entiteettejä on voitu muokata tai poistaa niiden lataamisen jälkeen. Katso http://go.microsoft.com/fwlink/?LinkId=472540 saadaksesi tietoa optimististen samanaikaisten poikkeusten ymmärtämisestä ja käsittelystä.
Testaa ero Timestampin ja ConcurrencyCheckin välillä
UpdateTab1-päivitys onnistui! Nimi 1
UpdateTab2-päivitys onnistui! Nimi 1
UpdateTab2-päivitys on epänormaali! Nimeä kaksi, epänormaalia tietoa! Store update, insert or delete -lause vaikutti odottamattomaan määrään rivejä (0). Entiteettejä on voitu muokata tai poistaa niiden lataamisen jälkeen. Katso http://go.microsoft.com/fwlink/?LinkId=472540 saadaksesi tietoa optimististen samanaikaisten poikkeusten ymmärtämisestä ja käsittelystä.
UpdateTab1-päivitys onnistui! Nimi 2
【Aikaleima】
TimeStamp-ominaisuutta voidaan soveltaa kenttäluokkaan, jolla on vain yksi tavullinen taulukkoominaisuus, ja tämä ominaisuus asettaa tiemStamp-tyypin sarakkeelle. Samanaikaisissa tarkistuksissa Code-First käyttää automaattisesti tätä TimeStamp-tyyppikenttää.
【ConcurrencyCheck】
ConcurrencyCheck-ominaisuutta voidaan soveltaa domain-luokan ominaisuuksiin. Kun EF suorittaa päivitysoperaation, Code-First asettaa sarakkeen arvon where-ehtolauseeseen, ja voit käyttää tätä CurrencyCheck-ominaisuutta käyttääksesi olemassa olevia sarakkeita rinnakkaistarkistukseen, sen sijaan että käyttäisit erillistä TimeStamp-saraketta rinnakkaistarkistukseen.
Aloitetaan luomalla uusi kontekstiobjekti, jolla havainnollistetaan ero Timestampin ja ConcurrencyCheckin välillä rinnakkaiskäsittelyssä!
Tässä on koodi kontekstiin:
Katsotaanpa tietokannan sarakkeita seuraavasti:
Huomaamme, että välilehdellä 1 ja välilehdellä 2 on Id-, Nimi- ja Huomautus-sarakkeet, ja välilehdellä 2 on enemmän Riviversio-sarakkeita kuin välilehdellä 1.
Liitä testikoodi ensin:
【ConcurrencyCheck Principle】
Lisäsimme ConcurrencyCheck -ominaisuuden Tab1:n Recomment-ominaisuuteen,
Kun päivitämme saman datan Nimi-attribuutin arvon samaan aikaan, poikkeusta ei tule!
Luo SQL-lauseita:
exec sp_executesql N'UPDATE [dbo]. [Välilehti 1]
SET [Nimi] = @0
MISSÄ (([id] = @1) JA ([Huomautus] = @2))
',N'@0 nvarchar(max) ,@1 int,@2 nvarchar(max) ',@0=N'name1',@1=1,@2=N'Note1' exec sp_executesql N'UPDATE [dbo]. [Välilehti 1]
SET [Nimi] = @0
MISSÄ (([id] = @1) JA ([Huomautus] = @2))
',N'@0 nvarchar(max) ,@1 int,@2 nvarchar(max) ',@0=N'name2',@1=1,@2=N'note1'
Kun päivitämme saman datan Remark-ominaisuuden arvon samanaikaisesti, heitetään poikkeus!
Luo SQL-lauseita:
exec sp_executesql N'UPDATE [dbo]. [Välilehti 1]
SET [Huomautus] = @0
MISSÄ (([id] = @1) JA ([Huomautus] = @2))
',N'@0 nvarchar(max) ,@1 int,@2 nvarchar(max) ',@0=N'Note1',@1=1,@2=N'Note' exec sp_executesql N'UPDATE [dbo]. [Välilehti 1]
SET [Huomautus] = @0
MISSÄ (([id] = @1) JA ([Huomautus] = @2))
',N'@0 nvarchar(max) ,@1 int,@2 nvarchar(max) ',@0=N'Note 2',@1=1,@2=N'Note'
Voimme huomata, että jos otamme saman datan Id 1:llä samanaikaisesti, saamme Remark-attribuutin arvon, ja kun päivitämme Remark-attribuuttia, käytämme Remark-ominaisuutta päivitysehtona.
Ensimmäinen sql-lause voidaan päivittää onnistuneesti, ja sitten huomautus muutetaan muotoon "note 1", ja kun toinen sql-lause päivitetään, päivitys epäonnistuu, koska huomautuksen arvo on muuttunut.
【Aikaleimaperiaate】
Lisäsimme RowVersion-ominaisuuden Tab2:een (voit ottaa minkä tahansa nimen) ja lisäsimme Timestamp-ominaisuuden!!
Kun päivitämme saman datan Name-arvon samaan aikaan, ensimmäinen päivitys onnistuu, toinen epäonnistuu ja poikkeus heitetään – katsotaanpa generoitua SQL-koodia!
exec sp_executesql N'UPDATE [dbo]. [Välilehti 2]
SET [Nimi] = @0
MISSÄ ((([id] = @1) JA ([RowVersion] = @2)) JA ([Huomautus] = @3))
VALITSE [RowVersion]
FROM [dbo]. [Välilehti 2]
MISSÄ @@ROWCOUNT > 0 JA [Id] = @1',N'@0 nvarchar(max) ,@1 int,@2 binary(8),@3 nvarchar(max) ',@0=N'Name1',@1=1,@2=0x00000000000007D1,@3=N'Note' exec sp_executesql N'UPDATE [dbo]. [Välilehti 2]
SET [Nimi] = @0
MISSÄ ((([id] = @1) JA ([RowVersion] = @2)) JA ([Huomautus] = @3))
VALITSE [RowVersion]
FROM [dbo]. [Välilehti 2]
MISSÄ @@ROWCOUNT > 0 JA [Id] = @1',N'@0 nvarchar(max) ,@1 int,@2 binary(8),@3 nvarchar(max) ',@0=N'name2',@1=1,@2=0x00000000000007D1,@3=N'Note'
Kun suoritetaan toista SQL-lausetta, koska where-ehdon tietoja ei enää löydy, päivitys epäonnistuu ja poikkeus heitetään pois!!
Kun ensimmäinen sql-lauseke on suoritettu onnistuneesti, RowVersionin arvo muuttuu, kuten alla olevassa kuvassa näkyy:
RowsVersion on aikaleima
Kiertotie puuttuviin päivityksiin
Puuttuvien päivitysten käsite: Kun käyttäjät muokkaavat datariviä samanaikaisesti, he ensin lukevat tiedot, laittavat sen käyttöliittymään muokkattavaksi ja lähettävät tiedot muokatessaan, jolloin lopullinen lähetetty data korvaa aiemmin lähetetyt tiedot, mikä aiheuttaa kadonneen päivityksen.
Lyhyesti sanottuna, tässä on keinoja estää päivitysten katoaminen:
Käytä RowsVersion-aikaleimaa.
Jos rivi on ristiriidassa ennen lukemista arvon kanssa, se tarkoittaa, että toinen transaktio on päivittänyt tämän sarakkeen, joten tätä saraketta ei voi päivittää, mikä estää päivitysten menetyksen.
Lopuksi liitä lähdekoodi:
CodeFirstDemo.rar
(4.94 KB, Latausten määrä: 13)
|
Julkaistu 8.4.2017 0.10.50
|
|
|
|
Julkaistu 22.3.2022 11.51.38
|
Vuokraisäntä|
Julkaistu 1.11.2023 20.42.15
|
