optimistic/pessimistic offline lock
DESCRIPTION
Při práci s databází se musíme poměrně často potýkat s problematikou vícenásobného souběžného přístupu k datům. Prezentace se zabývá touto problematikou, představuje dva mechanismy řešící souběžné transakce: pessimistic a optimistic offline lock. Dále zmiňuje možné problémy každého z těchto přístupů a na závěr vzájemně porovná vhodnost jejich použití v různých případech. Autoři: Luboš Krčál, Ondřej Machulda - ČVUT FELTRANSCRIPT
Optimistic Offline Lockvs
Pessimistic Offline Lock
Luboš KrčálOndřej Machulda
ČVUT FELY36ASS - Architektura SW systémůLS 2011
Offline lock
ProblémSouběžný přístup k datůmZabránit nekonzistenci v datech
Vzájemné přepisování datČtení starých dat
Business transakce přes několik systémových transakcí
PříkladDatabáze
Jak na to?Optimistic offline lock
Možný konflikt při commituPessimistic offline lock
Zabránit za každou cenu konfliktu
Optimistic offline lock
Optimistic offline lock
PrincipFakticky nefunguje jako zámek – data nezamykáHlídá, která data byla změněna (znevalidována pro ostatní transakce)
Pre-commit validationBusiness transakce získá OOL pouze pokud od doby načtení dat do pokusu o
jejich změně nedošlo ke změně těchto dat jinou stranouPokud se transakce pokusí přepsat nevalidní data – konfliktPokud tato transakce získá OOL, teprve tedy dojde ke změně těchto dat v
databázi
Řešení kolizíIgnorování kolize a přepsání dat v nové transakciVyřešení: uživatelem, automatickyNeřešit a zalogovat
PředpokladNízký počet konfliktůMalá ztráta v případě neúspěšné transakce
Optimistic offline lock – verzovací implementace
Verzovací implementacePři získání dat se k session uloží i aktuální verze těchto datPři pokusu o změnu dat se porovná verze dat ze session s verzí dat v systému:
Pokud se verze neliší, session získá OOL a je jí umožněno data změnitInkrementuje se verze
Pokud se verze liší – konflikt
Není vhodné použivat timestamp ani jeho varianty zavislé na systémovém čase – nespolehlivé
Vhodnější je používat obyčejný integer
Často se spolu s aktuální verzí záznamu v systému ukládá i čas a autor poslední změny
Optimistic offline lock – SQL implementace
SQL implementacePři čtení dat (SELECT) se načtou data včetně hodnoty verzeU každého SQL dotazu změny (UPDATE, DELETE)
V podmínce (WHERE) je číslo verze v session získaná při načítání datZměna dat zároveň mění (SET) i číslo verze
Tento přístup zesložiťuje SQL dotazy a může být pomalý v závislosti na databázovém stroji
Optimistic offline lock – Nekonzistentní čtení
Nekonzistentní čtení datKontrola verze dat při změně dat neznamená, ze v průběhu business transakce
nemůžeme načíst data změněná někým jinýmPokud na začátku transakce nevíme, jaká data budeme / můžeme potřebovat,
neexistuje rozumné řešeníJe potřeba znát, která data se mají kontrolovat
Při zápisu dat se ověří, zda i data načtená (byť neměněná v průběhu transakce) odpovídají svou verzí verzi session
Může způsobit problémy v závislosti na izolaci dat v rámci systémové transakce (databáze), takže se budou znovu čtená data jevit stejně
Provede umělou změnu takovýchto dat se stejnou hodnotou a s inkrementovanou verzí
Může být pomalé při závislosti na velkém objemu dat
Coarse-grained lock umožňuje zamykat skupinu dat jako jediný zamykatelný objekt (Person 1 --- * Address)
Optimistic offline lock – ukázka implementace
Optimistic offline lock – ukázka souběhu
Verze se tedy liší,provedeme rollback
Uložíme také inkrementovanýčítač verze
Uživatel 1
Uživatel 2
Načteme verzi, ta již ale bylainkrementována souběžnou operací
Optimistic offline lock – Použití
PoužitíKdyž očekáváme málo konfliktů
Konflikt je ztráta – uživatel ho musí často řešitJednoduchý na implementaciPokud stačí, není třeba ho doplňovat o jiné zámky
Použití v praxiVerzovací systémy: SVN, Git,…
Při konfliktu umožní uživateli spravit situaciPokud to jde, provede sám merge a znovu se pokusí o provedení commitu
MediaWikiJPA 2.0Google App Engine
Pessimistic offline lock
Pessimistic offline lock
PrincipZamyká data vůči určité úrovni přístupu
Exclusive Write Lock: Pro zápis dat je potřeba získat zámek. Neřeší čtení ani nehlídá, jestli někdo data změní těsně předtím.
Exclusive Read Lock: Zámek je potřeba pro načtení dat. Jejich použití nehraje roli. Dokud je zámek aktivní, nikdo jiný s daty nemůže jakkoliv manipulovat.
Read/Write Lock: Kombinace předchozích. Systém umožňuje získat buď zámek na čtení nebo na zápis. Je možnost existence souběžných zámků na čtení. Zámek na zápis tedy nikdy nemůže existovat spolu s jiným zámkem (na čtení ani na zápis).
Řešení zamítnutíVyčkání na přidělení zámkuZrušení transakce
PředpokladVysoký počet konfliktůVelká cena za konflikt v pozdější fázi business transakce
Pessimistic offline lock – Lock Manager
Lock managerLock manager spravuje zámky a uživatele (business transakce).Ideálně centralizovaný, jednoduchý a jediný (singleton)Pokud nemůže být centralizovaný (distribuované systémy), je lepší použít
zamykání založené na databáziPři potřebě spousty roztroušených zámků na různá data je vhodné uvažovat o
nasazení Coarse-Grained Lock
Pessimistic offline lock – Deadlock a Timeout
DeadlockPrvní session uzamkne data A a potřebuje i zámek na data BZároveň druhá session uzamkne data B a potřebuje i data AVzniklý deadlock není efektivní řešit na straně session timeoutemNejlepší možné řešení je zrušit transakci při prvním nedostupném zámku
Může naopak vézt ke zbytečnému rušení transakcí
TimeoutPokud vypadne klient aniž by ukončil transakci, tj. uvolnil zámky, mohou být
data blokovaná příliš dlouhoŘešení:
Timeout na straně aplikaceTimestamp jako atribut zámku – po uplynutí určité doby bude zámek
neplatný
Pessimistic offline lock – ukázka souběhu
Uživatel 1
Uživatel 2
Zámek nelze získat, drží jej souběžná operace
Získáme zámek
Zámek uvolníme
Pessimistic offline lock – Použití
PoužitíPředpokládáme vznik konfliktů => nutno řídit souběžné operaceNechceme zahazovat data v případě konfliktu v pozdější fázi transakceIdeálně pokud je doba uzamčení krátká
Použití v praxiJPA 2.0Hibernate
Ostatní vzory a shrnutí
Overly Optimistic Lock
PrincipOverly optimistic lock nezamyká ani nijak nekontroluje souběžný přístup k datům
PoužitíAppend-only data
LogyRead-only dataJednouživatelské systémy
Coarse-grained lock
PrincipUcelená skupina souvisejících datPři vyžádání zámku k nějakým datům z této skupiny dojde k zamčení celé skupiny
Implicit lock
PrincipNěkdo hlídá přístup k datům a zajišťuje automatické zamykáníEliminuje se tak spousta potenciálních chyb spojených s ručním hlídáním zámků
Optimistic vs Pessimistic offline lock – Výhody a Nevýhody
Optimistic Offline Lock
Výhody:Nemusí si udržovat spojení s
databázíNemusí nic zamykatČtení dat nikoho neomezujeJednodušší implementace
Nevýhody:Hrozí konflikt
Pessimistic Offline Lock
Výhody:Bezkonfliktní
Nevýhody:VýkonNutné spojení s databázíObtížná škálovatelnost
Optimistic vs Pessimistic offline lock - Shrnutí
Jakou implementaci?Je potřeba zvážit:
Jaký je poměr editací a prohlížení (read-only)?Jaká je pravděpodobnost souběhu přístupů?Do jaké míry je zamykání nahraditelné systémovou transakcí?Délka prováděných transakcíCena za konfliktCena za dirty read
Implementace se vzájemně doplňují! Nejsou výlučné!Související vzory
Coarse-grained LockImplicit LockIdentity Map