�ݺ�ߣ

Optimistic Offline Lock
vs
Pessimistic Offline Lock

Luboš Krčál
Ondřej Machulda

ČVUT FEL
Y36ASS - Architektura SW systémů
LS 2011

Offline lock
Problém
Souběžný přístup k datům
Zabrá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říklad
Databáze

Jak na to?
Optimistic offline lock
Možný konflikt při commitu
Pessimistic offline lock
Zabránit za každou cenu konfliktu

Optimistic offline lock
Princip
Fakticky nefunguje jako zámek – data nezamyká
Hlídá, která data byla změněna (znevalidována pro ostatní transakce)
Pre-commit validation
Business 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 stranou
Pokud se transakce pokusí přepsat nevalidní data – konflikt
Pokud 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é transakci
Vyřešení: uživatelem, automaticky
Neřešit a zalogovat
Předpoklad
Nízký počet konfliktů
Malá ztráta v případě neúspěšné transakce

Optimistic offline lock – verzovací implementace
Verzovací implementace
Při získání dat se k session uloží i aktuální verze těchto dat
Př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ěnit
Inkrementuje 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/Pessimistic Offline Lock

Optimistic offline lock – SQL implementace
SQL implementace
Při čtení dat (SELECT) se načtou data včetně hodnoty verze
U 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í dat
Změ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í dat
Kontrola 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ým
Pokud 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

Uživatel 1

Uživatel 2

Načteme verzi, ta již ale byla
inkrementována souběžnou operací

Uložíme také inkrementovaný
čítač verze

Verze se tedy liší,
provedeme rollback

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šit
Jednoduchý na implementaci
Pokud stačí, není třeba ho doplňovat o jiné zámky

Použití v praxi
Verzovací systémy: SVN, Git,…
Při konfliktu umožní uživateli spravit situaci
Pokud to jde, provede sám merge a znovu se pokusí o provedení commitu
MediaWiki
JPA 2.0
Google App Engine

Pessimistic offline lock
Princip
Zamyká 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ámku
Zrušení transakce
Předpoklad
Vysoký počet konfliktů
Velká cena za konflikt v pozdější fázi business transakce

Pessimistic offline lock – Lock Manager
Lock manager
Lock 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ázi
Př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
Deadlock
První session uzamkne data A a potřebuje i zámek na data B
Zároveň druhá session uzamkne data B a potřebuje i data A
Vzniklý deadlock není efektivní řešit na straně session timeoutem
Nejlepší 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í

Timeout
Pokud vypadne klient aniž by ukončil transakci, tj. uvolnil zámky, mohou být
data blokovaná příliš dlouho
Řešení:
Timeout na straně aplikace
Timestamp 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ískáme zámek

Zámek nelze získat, drží jej
souběžná operace

Zámek uvolníme

Pessimistic offline lock – Použití
Použití
Předpokládáme vznik konfliktů => nutno řídit souběžné operace
Nechceme zahazovat data v případě konfliktu v pozdější fázi transakce
Ideálně pokud je doba uzamčení krátká

Použití v praxi
JPA 2.0
Hibernate

Ostatní vzory a ��Գܳ�í

Overly Optimistic Lock
Princip
Overly optimistic lock nezamyká ani nijak nekontroluje souběžný přístup k datům

Použití
Append-only data
Logy
Read-only data
Jednouživatelské systémy

Coarse-grained lock
Princip
Ucelená skupina souvisejících dat
Při vyžádání zámku k nějakým datům z této skupiny dojde k zamčení celé skupiny

Implicit lock
Princip
Ně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 Pessimistic Offline Lock

Výhody: Výhody:
Nemusí si udržovat spojení s Bezkonfliktní
databází
Nemusí nic zamykat Nevýhody:
Čtení dat nikoho neomezuje Výkon
Jednodušší implementace Nutné spojení s databází
Obtížná škálovatelnost
Nevýhody:
Hrozí konflikt

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 konflikt
Cena za dirty read
Implementace se vzájemně doplňují! Nejsou výlučné!
Související vzory
Coarse-grained Lock
Implicit Lock
Identity Map

�ݺ�ߣ

Optimistic/Pessimistic Offline Lock

More Related Content

Optimistic/Pessimistic Offline Lock