Optimistic/Pessimistic Offline Lock

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