Offline concurrency patterns Petr Smrček Ondřej Svoboda ČVUT FEL A7B36ASS – Architektura SW sytémů LS 2013.

Prezentace na téma: "Offline concurrency patterns Petr Smrček Ondřej Svoboda ČVUT FEL A7B36ASS – Architektura SW sytémů LS 2013."— Transkript prezentace:

1 Offline concurrency patterns Petr Smrček Ondřej Svoboda ČVUT FEL A7B36ASS – Architektura SW sytémů LS 2013

2 Offline concurrency patterns Problém  systémové (databázové) transakce by měly být krátké  business transakce mohou být velmi dlouhé Příklad: editace záznamu  uživatel přečte z databáze záznam  v editačním formuláři upravuje data  data uloží, mezitím s nimi ale mohl pracovat někdo jiný Jak na to?  je třeba řešit aplikační logikou – business transaction Způsoby řešení  Optimistic offline lock  Pessimistic offline lock  Coarse-grained lock  Implicit lock

3 Optimistic offline lock

4 Kdy použít  kolize mezi transakcemi nejsou příliš očekávané  nevadí, pokud transakce na konci spadne a práce bude ztracena Princip  práce s daty je povolena všem  pokud by mělo dojít ke konfliktu, transakce je neúspěšná (rollback) Implementace  nejčastěji použitím verzí  každá úprava daného záznamu inkrementuje jeho verzi  konflikt nastane, pokud se má upravit záznam s vyšší verzí, než jakou měl při čtení  implementace je jednoduchá

5 Optimistic offline lock – příklad

6

7 Optimistic offline lock – SQL implementace UPDATE Customer SET..., version = (session’s version + 1) WHERE id = 129 AND version = (session’s version)

8 Optimistic offline lock – aplikační implementace Customer c = customerDao.getCustomer(); /* do application logic */ Transaction::begin(); if (customerDao.checkVersion(c.version)) { c.save(); Transaction::commit(); } else { Transaction::rollback(); }

9 Optimistic offline lock – nekonzistentní čtení dat Nekonzistentní čtení dat  kontrola verzí pouze při UPDATE nebo DELETE neřeší následující problém:  v transakci používáme i data, která neměníme, ale výsledek transakce na nich závisí Umělá úprava dat  nad těmito daty provedeme taktéž UPDATE, ale změníme pouze verzi  + není třeba žádná další zamykací logika  - zbytečný zápis, zbytečně označujeme pro ostatní transakce stejná data různou verzí Ruční kontrola verze  pro tato data si pomatujeme původní verzi a zvlášť jí kontrolujeme  + efektivní řešení  - je třeba dát pozor na stupeň izolace systémových transakcí (je potřeba repeatable read či silnější), aby nám neprezentovaly stejnou verzi Coarse-grained lock

10 Optimistic offline lock – použití Verzovací systémy  SVN, Git,...  při konfliktu řeší uživatel JPA 2.0  @Version int version; MediaWiki

11 Pessimistic offline lock

12 Pravděpodobnost konfliktu je velká  preventivně zabránit vzniku konfliktu  nejobvyklejší implementace – zamykání zdrojů  business transakce musí získat zámek zdroje před tím, než se zdrojem začne pracovat Zamykání zdrojů  Exclusive Write Lock – nikdo nesmí data číst, ani zapisovat  Shared Read Lock  Data jsou zamknuta pro čtení  Více transakcí může číst, ale ne zapisovat  kompatibilita zámků: SH × SH ano, SH × EX ne, EX × EX ne Řešení zamítnutí  transakci zrušit  počkat na zámek

13 Pessimistic offline lock

14

15 Pessimistic offline lock – Lock manager Lock manager  udržuje v paměti seznam zamčených objektů  pokud aplikace běží na clusteru serverů, musí být tento seznam uložen v databázi  business transakce nemanipuluje se zámky přímo, ale pouze přes lock managera Práce lock managera  kdy zamknout – dříve než začnu se zdroji pracovat  jistota, že mám nejaktuálnější verzi zdroje  co zamknout – typicky ID zdroje  kdy odemknout – nejlépe na konci transakce  co dělat když nelze získat zámek – nejjednodušší je transakci zrušit (rollback)

16 Pessimistic offline lock - Deadlock Deadlock  transakce 1 drží lock na zdroj 1 a požaduje zámek na zdroj 2  transakce 2 drží lock na zdroj 2 a požaduje zámek na zdroj 1  protože obě transakce nemohou pokračovat dokud nebudou zdroje volné a obě transakce nemohou uvolnit zámky, vzniká deadlock Řešení  nečekat na zámky  zrušit transakci při prvním nedostupném zámku

17 Pessimistic offline lock – Lost transactions Lost transactions  klientský proces spadne uprostřed transakce  u webové aplikace typicky uživatel transakci nedokončí  transakce neuvolnila zámky Řešení  timeout na úrovni aplikace  timeout na úrovni aplikačního serveru  timeout http session  po timeoutu se uvolní / invalidují zámky

18 Pessimistic offline lock - Použití Použití  tam kde předpokládáme vznik konfliktů - nutnost řídit souběžné operace  nebo uživatel nesmí přijít ani o část své práce  rollback transakce nemusí být vždy možný Implementace  JPA 2 - Hibernate @Override @Transactional public void updateBalance(String id, BigDecimal amount) { Account acc = (Account) sessionFactory.getCurrentSession().get(Account.class, id, LockMode.UPGRADE); acc.setBalance(acc.getBalance().subtract(amount)); save(acc); }

19 Coarse-grained lock Implicit lock

20 Coarse-grained lock  zamykání skupin objektů jedním zámkem Výhody proti zamykání jednotlivých objektů  Optimistické zamykání – pro zamčení (načtení verzí) je potřeba načíst velké množství objektů  Pesimistické zamykání – rozsáhlá tabulka záznamů

21 Coarse-grained lock – optimistické zamykání Sdílený objekt verze

22 Coarse-grained lock – pesimistické zamykání Zamykání sdíleného objektu verze

23 Coarse-grained lock – pesimistické zamykání Zamykání kořene

24 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ů

25 Offline concurrency patterns – shrnutí Co řeší?  dlouhé transakce na úrovni aplikační logiky Možnosti implementace  Optimistic offline lock – jednoduchá implementace, kolize nejsou moc očekávány  Pessimistic offline lock – kolize očekávány, preventivní ochrana  Coarse-grained lock – sjednocení více objektů pod jeden zámek  Implicit lock – zámky řešeny automaticky např. frameworkem Související vzory  Overly optimistic lock strategie spoléhající na to, že žádné kolize nenastanou  Identity map zajišťuje, že každý objekt bude načten pouze jednou

26 Zdroje Martin Fowler - Catalog of Patterns of Enterprise Application Architecture (http://martinfowler.com/eaaCatalog/)http://martinfowler.com/eaaCatalog/ Enterprise Architecture Patterns (http://cw.felk.cvut.cz/lib/exe/fetch.php/courses/a7b39wpa/wpa2.pdf)http://cw.felk.cvut.cz/lib/exe/fetch.php/courses/a7b39wpa/wpa2.pdf The Addison-Wesley Signature Series (http://ideababy.ru/0321127420_ch16.shtml)http://ideababy.ru/0321127420_ch16.shtml