Szerzőwww.itsvse.com @小渣渣 !
Sikeresen beilleszteted az alapadatokat!
A ConcurrencyCheck funkció tesztelése befejeződött
Frissítés sikeres! 1. megjegyzés
A frissítés kivételes! Megjegyzés 2, rendkívüli információ! A Store update, insert vagy delete utasítás váratlan számú sort érintett (0). Az entitások betöltése óta módosítódhattak vagy törölhettek. Lásd http://go.microsoft.com/fwlink/?LinkId=472540 az optimista egyidejű kivételek megértését és kezelését szolgáló információkért.
Teszteld a különbséget az Időbélyeg és a ConcurrencyCheck között
FrissítésTab1 frissítés sikeres! Név 1
FrissítésTab2 frissítés sikeres! Név 1
A UpdateTab2 frissítés szokatlan! Nevezz 2-t, rendellenes információ! A Store update, insert vagy delete utasítás váratlan számú sort érintett (0). Az entitások betöltése óta módosítódhattak vagy törölhettek. Lásd http://go.microsoft.com/fwlink/?LinkId=472540 az optimista egyidejű kivételek megértését és kezelését szolgáló információkért.
FrissítésTab1 frissítés sikeres! Név 2
【TimeStamp】
A TimeStamp funkció alkalmazható a mezőosztályra, amelynek csak egy bájtos tömbtulajdonsága van, és ez a funkció a tiemStamp típust az oszlophoz állítja. Egyidejű ellenőrzéseknél a Code-First automatikusan ezt a TimeStamp típusú mezőt használja.
【ConcurrencyCheck】
A ConcurrencyCheck funkció alkalmazható egy domain osztály tulajdonságaira. Amikor az EF frissítési műveletet végez, a Code-First az oszlop értékét a where feltétel állításba helyezi, és ezt a CurrencyCheck funkciót használhatod a meglévő oszlopok ellenőrzésére, ahelyett, hogy külön TimeStamp oszlopot használnál az egyidejű ellenőrzéshez.
Kezdjük egy új kontextusobjektum létrehozásával, hogy bemutassuk a különbséget az Timestamp és a ConcurrencyCheck között a párhuzamos feldolgozásban!
Íme a kontextus kódja:
Nézzük meg az adatbázis oszlopait a következőkben:
Azt fogjuk tapasztalni, hogy az 1-es és 2-es tabokban Id, Név és Megjegyzés oszlopok vannak, míg a 2-es tabon több Sorverzió oszlopot tartalmaz, mint az 1-es tab.
Először csatold a tesztkódot:
【ConcurrencyCheck Principle】
Hozzáadtuk a ConcurrencyCheck funkciót a Tab1 Megjegyzés tulajdonságához,
Amikor ugyanabban az adatban frissítjük a Name attribútumértéket, nem kerül kivétel!
SQL utasítások generálása:
exec sp_executesql N'UPDATE [dbo]. [Tab1]
SET [Név] = @0
AHOL (([Id] = @1) ÉS ([Megjegyzés] = @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 [Név] = @0
AHOL (([Id] = @1) ÉS ([Megjegyzés] = @2))
',N'@0 nvarchar(max) ,@1 int,@2 nvarchar(max) ',@0=N'name2',@1=1,@2=N'note1'
Amikor ugyanabban az adatban frissítjük a Remark tulajdonság értékét, kivételt adunk!
SQL utasítások generálása:
exec sp_executesql N'UPDATE [dbo]. [Tab1]
BEÁLLÍTÁS [Megjegyzés] = @0
AHOL (([Id] = @1) ÉS ([Megjegyzés] = @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]
BEÁLLÍTÁS [Megjegyzés] = @0
AHOL (([Id] = @1) ÉS ([Megjegyzés] = @2))
',N'@0 nvarchar(max) ,@1 int,@2 nvarchar(max) ',@0=N'Note 2',@1=1,@2=N'Note'
Azt tapasztalhatjuk, hogy ha ugyanazt az adatdarabot egyszerre veszjük fel az 1-es azonosítóval, megkapjuk a Remark attribútum értékét, és a Remark attribútumot frissítő feltételként használjuk.
Az első sql utasítás sikeresen frissíthető, majd a megjegyzés "note 1"-re változik, és amikor a második sql kijelentést frissítik, a frissítés megbukik, mert a megjegyzés értéke megváltozott.
【Időbélyeg-elv】
Hozzáadtunk egy RowVersion tulajdonságot a Tab2-hez (bármilyen nevet vehetsz), és hozzáadtuk az Időbélyeg funkciót!!
Amikor ugyanabban az időben frissítjük ugyanazon adat névértékét, az első frissítés sikeres, a második sikertelen, és kivétel jelenik meg, nézzük meg a generált SQL kódot!
exec sp_executesql N'UPDATE [dbo]. [Tab2]
SET [Név] = @0
AHOL ((([Id] = @1) ÉS ([RowVersion] = @2)) ÉS ([Megjegyzés] = @3))
SELECT [RowVersion]
FROM [dbo]. [Tab2]
AHOL @@ROWCOUNT > 0 ÉS [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]. [Tab2]
SET [Név] = @0
AHOL ((([Id] = @1) ÉS ([RowVersion] = @2)) ÉS ([Megjegyzés] = @3))
SELECT [RowVersion]
FROM [dbo]. [Tab2]
AHOL @@ROWCOUNT > 0 ÉS [Id] = @1',N'@0 nvarchar(max) ,@1 int,@2 binary(8),@3 nvarchar(max) ',@0=N'name2',@1=1,@2=0x00000000000007D1,@3=N'Note'
A második SQL utasítás végrehajtásakor, mivel a where feltétel adatai már nem találhatók, a frissítés megbukik, és kivétel keletkezik!!
Az első SQL utasítás sikeres végrehajtása után a RowVersion értéke változni fog, ahogy az alábbi ábrán látható:
A RowsVersion időbélyeg
Megoldás a hiányzó frissítésekre
A hiányzó frissítések fogalma: Amikor a felhasználók egyszerre módosítanak egy adatsort, először elolvassák az adatokat, a módosítandó felületre teszik az adatokat, majd a módosításkor benyújtják az adatokat, így a végleges beküldött adatok felülírják a korábban beküldött adatokat, ami a frissítés elvesztését okozza.
Röviden: íme néhány módszer annak, hogy elkerüld a frissítések elvesztését:
Használd a RowsVersion időbélyeget.
Ha egy sor nem egyezik az olvasás előtti értékkel, az azt jelenti, hogy egy másik tranzakció frissítette ezt az oszlopot, így ezt az oszlopot nem lehet frissíteni, így elkerülve a frissítések elvesztését.
Végül csatoljuk a forráskódot:
CodeFirstDemo.rar
(4.94 KB, Letöltések száma: 13)
|
Közzétéve 2017. 04. 08. 0:10:50
|
|
|
|
Közzétéve 2022. 03. 22. 11:51:38
|
Háziúr|
Közzétéve 2023. 11. 01. 20:42:15
|
