Konkurenční přístup k datům - zamykací mechanismy, díl třetí

Jak jsem již zmiňoval v předchozím díle, dnes bych se věnoval tzv. offline zamykacím mechanismům. Offline zamykací mechanismy přicházejí v úvahu, když nemůžeme využít online (předchozí) mechanismy, tj. hlavně když

• jedna transakce by běžela příliš dlouho
• realizace případu užití se skládá z více transakcí

Optimistické offline zamykání

Pokud bych to měl stručně vyjádřit, tak myšlenka a implementace je velice podobná jako u optimistického zamykání z prvního dílu, jen s tím rozdílem, že zde se nepohybujeme pouze v rámci jedné transakce.

Příklad:

• Transakce A1 načte objednávku a uloží číslo verze (nebo jinou informaci, podle které je možné rozlišit různé verze objektu) do session.
• Transakce B1 načte a zruší objednávku, což způsobí změnu verze
• Transakce A2 se pokusí změnit objednávku. Protože se změnil stav objednávky resp. se změnila verze, tak změna neprojde.

Implementace: jak již bylo naznačeno, optimistické zamykání funguje na principu porovnání stavu objektu po načtení a před úpravou. Toho lze docílit buď evidencí verze, časového razítka nebo přímo porovnáním hodnot. Offline porovnání má ještě to specifikum, že je potřeba informaci o verzi uchovat přes více transakcí. Vhodné úložiště je uživatelská session.

Pro optimistické offline zamykání se nabízí ještě jedna možnost implementace - přes detašované objekty. Načtu objekt z databáze a uložím detašovanou verzi objektu někde bokem, např. v uživatelské session. Uživatel provede operaci, hodnoty detašovaného objektu se nám změní. Aplikace se pokusí převést tento objekt znovu do persistentního stavu a zde nám ORM nástroj dá sám vědět, zda pracujeme pořád nad stejnou verzí objektu nebo ne.
Výhodou tohoto řešení je, že aplikace sama nemusí řešit porovnávání různých verzí objektů, to za nás udělá ORM knihovna. Také se zde neomezujeme pouze na jeden objekt, ale můžeme takto porovnat celý graf objektů.

Použití: vhodné pro takové případy užití, kde se pracuje s daty přes více transakcí, kde je malá pravděpodobnost konkurenčního přístupu nebo tolik nevadí návrat zpět po neúspěšném pokusu změny dat. Také se tento typ zamykání hodí pro ty případy, kde máme problémy se zajištěním vymazání zámku (viz dále pesimistické offline zamykání).

Popis s diagramem tohoto patternu lze nalézt na stránkách Martina Fowlera.

Myslel jsem, že ten můj miniseriál již dnes ukončím, ale bude ještě jeden díl - Pesimistické offline zamykání.