DPKOM_10 Transakce 1

DPKOM_10 Transakce 1

Obsah přednášky Motivace Transakce ACID Modely transakcí Dvoufázový protokol commit Transakce řízené kontejnerem, beanem a klientem Deklarativnířízení transakcí Transakční atributy Izolace a uzamykání databáze 2

Motivace Atomické operace Provedenířady diskrétních operací jako jedné pokračující atomické operace. Příklad výběr částky z jednoho účtu a její uložení na jiným účet. Chci aby se provedly obě operace dobře, nebo žádná jinak problém. try { // Withdraw money from account 1 } catch (Exception e) { // If an error occurred, do not proceed. return; } try { // Otherwise, deposit money into account 2 } catch (Exception e) { // If an error occurred, do not proceed, // and redeposit the money back into account 1. return; } 3

Motivace Atomické operace Problémy tohoto přístupu: kód je objemný a neohrabaný v každém kroku je třeba zvažovat možný potencionální problém, který může nastat a rutinu, která opraví chyby pomocí roll back změn. zpracování chyb se vymkne kontrole v případě vykonávání komplexnějších operací (obsluha více účtů současně); problém testování kódu. Ideálně chceme provedení všech operací, nebo žádné. 4

Motivace Chyba počítače nebo sítě Předpoklad, že logika bankovního účtu je distribuovaná ve více vrstvách rozmístění (deployment). Distribuce aplikace v síti způsobí chyby a problémy spolehlivosti. Co se např. stane při výpadku sítě během bankovních operací. Bank Application (with GUI) Tier Boundary Bank Logic Implementation 5

Motivace Chyba počítače nebo sítě Typicky je vyhozena výjimka (Java RMI RemoteException) pro kód klienta, která však není jednoznačná. Mohla vypadnout síť např. před výběrem peněz z účtu, nebo po výběru peněz z účtu nedá se to rozlišit. Kromě sítě mohou působit problémy perzistentní informace v databázi. kolaps samotné databáze, kolaps počítače na němž je rozmístěna databáze. Je třeba mít recovery process, který ošetří uvedené havárie. 6

Motivace Sdílení dat více uživateli Předpokládejme, že všechny aplikační servery sdílejí perzistentní data v jedné databázi. Aplikační servery tedy potenciálně mohou modifikovat stejnou množinu dat v databázi. Mohou vznikat irelevantní informace. Nutnost mechanismu, který zvládne řízení souběžně pracujících uživatelů na modifikaci dat databáze. 7

Aplikační servery a jedna databáze Client Code Client Code Client Code Client Code Application Server Application Server Application Server Databáze 8

Výhody transakcí Popsaným problémům se dá vyhnout správným používáním transakcí. Transakce řada operací, která se jeví při vykonávání jako jedna velká atomická operace. Transakce garantují all-or-nothing value proposition (všechny úspěšné nebo žádná úspěšná). Správné používání transakcí způsobí, že víceuživatelské interakce s databázemi (nebo jinými zdroji) se mohou provádět nezávisle. 9

Výhody transakcí Transakce navíc umožňují pokročilou formu souběžného (konkurentního) řízení a zpracování výjimek. 10

Vlastnosti ACID ACID atomicity, consistency, isolation, durability. Slovník transakce. Transakční objekt (transakční komponenta) je komponenta aplikace, která se zúčastní transakce. Transakční manažer je zodpovědný za řízení transakčních operací transakční komponenty. Řídí režijní entity transakce, které pracují za scénou a koordinují věci (dirigent diriguje symfonii). Zdroj je perzistentní paměť, ze kterého se dáčíst / zapisovat. 11

Vlastnosti ACID Manažer zdroje řídí zdroj např. driver pro relační databázi, objektovou databázi, frontu zpráv. Manažeři zdrojů jsou odpovědni za řízení všech stavů, které jsou permanentní. Nejpopulárnější rozhraní pro komunikaci mezi manažery zdroje a transakčním manažerem je X/Open XA resource manager interface. 12

Vlastnosti ACID Atomicity (atomičnost) garantuje, že mnoho operací může být svázáno spolu a jevit se jako pokračující jednotka práce. Consistency (konzistentnost) garantuje, že transakce zanechá konzistentní stav systému po svém vykonání. Isolation (izolace) chrání konkurentní vykonávání transakcí tak, aby žádná z nich neviděla nekompletní výsledky jiné. Tarnsakce o sobě navzájem nevědí. využívají se nízko-úrovňové synchronizační protokoly 13

Vlastnosti ACID Durability (trvanlivost) garantuje, že aktualizované, řízené zdroje přežijí havárie a výpadky. 14

Modely transakcí Nejpopulárnější flat transaction a nested transaction. Flat Transaction je to řada operací, které jsou vykonávány automaticky jako jedna jednotka práce (unit of work). při ukončení transakce je vždy binární výsledek success, failure. úspěšná transakce je provedena (committed), neúspěšná je zrušena (aborted). 15

Modely transakcí když je transakce provedena (committed), všechny perzistentní operace se stanou permanentními změnami; všechny aktualizace zdrojů jsou trvalé. při zrušení jsou všechny změny roll back. Hlavní důvody zrušení transakce Nevhodné parametry předané jedné z komponent. Porušení neměnného stavu systému přečerpání účtu. chyby HW a SW. 16

Vnořené transakce Vnořené transakce umožňují vnořit atomické jednotky práce do jiných jednotek práce. Vnořené transakce mohou reprezentovat strom transakcí. Kořenová transakce (root) a podtransakce (subtransactions). Další modely: zřetězené transakce 17

Distribuované transakce Distribuované transakce jsou transakce zasahující více vrstev rozmístění (deployment) a potenciálně zahrnující více typů zdrojů. Možné scénáře distribuovaných transakcí: více aplikačních serverů spolupracujících v jedné transakci; aktualizace různých databází ve stejné transakci; vykonání aktualizace databáze a poslání, nebo přijetí zprávy JMS z fronty zpráv ve stejné transakci; propojení na zděděný systém, jeden nebo více typů zdrojů ve stejné transakci. 18

Trvanlivost a dvoufázový protokol commit První fáze začíná zasláním zprávy before commit všem zdrojům zahrnutým v transakci. V této fázi mají zdroje zahrnuté v transakci poslední šanci tuto transakci zrušit. Všechny aktualizace zdrojů jsou zaznamenány do transakčních logů nebo journálů. Druhá fáze nastane pouze proběhne-li fáze jedna bez problémů. 19

Dvoufázový protokol commit V distribuovaném dvou fázovém commitu existuje jedna hlavní transakce nazvaná: distributed transaction coordinator. Cíle transakčního koordinátora: 1. Rozesílá zprávu prepare to commit každému transakčnímu manažerovi zahrnutém do dané transakce. 2. Každý transakční manažer může šířit tuto zprávu manažerům zdrojů, kteří jsou ve vazbě s transakčním manažerem. 20

Dvoufázový protokol commit 3. Každý transakční manažer podává zprávu zpět transakčnímu koordinátoru. Pokud všichni souhlasí s operací commit, je operace commit v případě krachu logována. 4. Transakční koordinátorřekne každému transakčnímu manageru, aby provedl commit. Každý transakční manažer volá každého manažera zdroje, který provede aktualizaci permanentní a trvalou. V případě chyby se použije vstup log k opakování posledního kroku. 21

Deklarativní transakční řízení Management Deklarativní transakčnířízení je implicitní rys Enterprise JavaBeans. Bez tohoto rysu by bylo třeba používat explicitní transakčnířízení jako např. Object Transaction Service nebo Java Transaction Service. Transakční chování EJBs může být řízeno s použitím anotace @javax.ejb.transactionattribute, nebo samozřejmě popisovačem rozmístění (deployment descriptor). Oba způsoby umožňují nastavit atributy transakce jednotlivých metod. 22

Deklarativní transakční řízení Management To znamená, že transakční chování EJB může být měněno beze změny business logiky, pouze anotací, nebo XML (popisovačem). Deklarativní transakčnířízení zjednodušuje složitost transakcí pro vývojáře EJB aplikací. 23

Transakce řízené kontejnerem, beanem a klientem Jakmile je transakce spuštěna, skončí buď commitem nebo abortem. Klíčové informace: kdo začne (spustí) transakci kdo vydá commit nebo abort kdy každý z těchto kroků nastane Podle toho kdo vymezí hranice transakce rozlišujeme styl řízení transakce a to: container managed bean managed client controlled 24

Transakce řízené kontejnerem, beanem a klientem Když používáme beanemřízené transakce, poskytovatel beanu (bean provider) je zodpovědný za programování transakční logiky v kódu aplikace. To znamená, že jste to vy, kdo vydá příkaz begin a commit nebo abort. U bankovní aplikace může bean působit jako bank teller. Teller bean vystaví (expose) metody pro převod peněz z jednoho účtu na druhý. 25

Beanem řízená transakce Client Code EJB Container 1. Call business method Container classes that implement session bean s POJO 2. Delegate Teller Bean 3. Call begin() 5. Call commit or abort Transaction Service 4. Perform buseness operations 26

Kontejnerem řízená transakce Tento typ transakce dovolí komponentám, aby byly vloženy do seznamu transakcí. To znamená, že bean nikdy explicitně nevydá příkaz begin, commit nebo abort. 27

Kontejnerem řízená transakce Client Code EJB Container 1. Call business method Container classes that implement session bean s POJO 2. Call begin() 3. Delegate 5. Call commit or abort Transaction Service Teller Bean 4. Perform buseness operations 28

Klientem řízená transakce Tato situace nastane pokud transakce začíná a končí z kódu klienta, mimo bean. Např. při použití servletu, JSP tag knihovny, samostatné aplikace nebo apletu. 29

Klientem řízená transakce Client Code 1. Call begin() 5. Call commit or abort Transaction Service EJB Container 2. Call business method Container classes that 3. Delegate implement Teller Bean session bean s POJO 4. Perform buseness operations 30

Rozsah Transakce Transacton Scope Rozsah transakce je základním pojmem v transakčním zpracování. Rozsah transakce odkazuje na beany (session a entitní), které se zúčastní konkrétní transakce. Rozsah transakce začíná, když klient vyvolá metodu bookpassage() TravelAgent beanu. Po zpoštění transakce, je tato dále šířena. Transakce musí být atomická (úspěšná, neúspěšná). Je snadné sledovat rozsah transakce sledováním tzv. vlákna vykonávání (thread of execution). 31

Rozsah Transakce Transacton Scope Transakce může být ukončena vyhozením výjimky. Kromě vlákna vykonávání, hrají také důležitou roli atributy transakce. EJ bean se může zúčastnit transakčního rozsahu libovolné unit of work implicitně prostřednictvím EJB s transakčních atributů, nebo explicitně prostřednictvím JTA. 32

Transakční atributy Jako vývojář aplikace normálně není třeba řídit transakce explicitně. Servery EJB umířídit transakce implicitně, pomocí transakčních atributů vytvořených v čase rozmístění. Je-li bean rozmístěn, je možné nastavit jeho transakční atribut pomocí anotace @javax.ejb.transactionattribute, nebo popisovačem rozmístění na několik hodnot: NotSupported, Supports, Required, RequiresNew, Mandatory, Never 33

Transakční atributy Transakční atributy je možné nastavit na celou transakci (jednodušší způsob), nebo na jednotlivé metody (flexibilnější způsob). 34

public enum TransactionAttributeType { MANDATORY, REQUIRED, REQUIRES_NEW, SUPPORTS, NOT_SUPPORTED, NEVER } Poznámky Anotace @TransactionAttrib ute @Target({METHOD Target({METHOD, TYPE}) public @interface TransactionAttribute { TransactionAttributeType value() default TransactionAttributeType.REQUIRED; } @TransactionAttribute může být použit na metodu, nebo na třídu beanu: import static TransactionAttributeType.*; @Stateless @ReansactionAttribute(NOT_SUPPORTED ReansactionAttribute(NOT_SUPPORTED) public class TravelAgentBean implements TravelAgentRemote { public void setcustomer(customer cust) {... } @TransactionAttribute(Required TransactionAttribute(Required) public TicketDO bookpassage(creditcarddo card, double price) {... } }

Transakční atributy Transakce klienta suspended znamená, že transakce není šířena (propagovaná) k vyvolané metodě EJB; šíření transakce je dočasně pozastaveno, dokud se metoda nedostane na return. 36

NotSupported, Supports NotSupported Vyvolání metody enterprise beanu suspenduje transakci dokud není metoda dokončena. Supports Atribut znamená, že metoda enterprise beanu bude začleněna do transakčního rozsahu, je-li vyvolána během transakce. 37

Required Required Atribut znamená, že metoda beanu musí být vyvolána uvnitř transakčního rozsahu. Je-li volající klient nebo beančástí transakce, bean s atributem required je automaticky začleněn do rozsahu transakce. Není-li volající klient nebo bean začleněn do transakce bean s atributem required začne svoji novou transakci. Rozsah nove transakce však zahrnuje pouze bean s atrubutem required a všechny jeho následné beany. 38

RequiresNew RequiresNew Atribut znamená, že se vždy odstartuje nová transakce. Nezáleží na tom, zda je volající klient, nebo bean částí transakce, metoda s uvedeným atributem začne při vyvolání novou transakci. Je-li volající klient již zahrnut do transakce, je tato transakce suspendována, dokud není u nove transakce dosaženo konce. 39

Mandatory Mandatory Atribut znamená, že metoda beanu musí být vždy částí transakčního rozsahu volajícího klienta. Bean nesmí startovat svoji vlastní transakci; transakce musí být šířena od klienta. Pokud volající klient neníčástí transakce, vyvolání skončí chybou a vyhozením výjimky. 40

Never Never Atribut znamená, že metoda beanu nesmí být vyvolána v rozsahu transakce. Je-li volající klient nebo beančástí transakce, bean s atributem never vyhodí výjimku. Pokud volající klient nebo bean není zahrnut do transakce, bean s atributem never bude vykonán normálně bez transakce. 41

Perzistence EJB 3.0 a transakční atributy Specifikace EJB silně doporučuje přístup v rozsahu JTA transakcí prostřednictvím EntityManageru. Pokud máte přístup k perzistentním entitám, používejte pouze transakční atributy: Required, RequiredNew a Mandatory. Toto omezení zabezpečí, že všechny přístupy do databáze budou pouze v kontextu transakce, což je důležité když kontejner řídí automaticky perzistenci. 42

Beany řízené zprávami a transakční atributy Beanyřízené zprávami mohou být deklarovány pouze s transakčními atributy NotSupported a Required. 43

Propagace transakcí Transaction Propagation Ukázka příkladu na metodě bookpassage() beanu TravelAgent. Defóltní transakční atribut Required. Commit učiní požadované změny permanentními. Pokud např. entita Reservation nemůže být vytvořena Entitním Managerem, změna vytvořené beanem ProcessPayment je odvalena zpět. Je třeba zabránit nekonzistentním datům v databázi. 44

Propagace transakcí Transaction Propagation V případech, kdy kontejner řídí implicitně transakci, rozhodnutí o commit nebo roll back jsou automaticky v působnosti kontejneru. Je-li transakce explicitněřízena beanem, nebo klientem jsou uvedená rozhodnutí na nich. 45

TravelAgent agent = (TravelAgent)jndi.lookup(( TravelAgent)jndi.lookup( TravelAgent TravelAgent ); agent.setcabinid(cabin_id); agent.setcruiseid(cruise_id); try { agent.bookpassage(card,, price); } catch(exception e) { System.out.println( Transaction failed! ); } Poznámky Předpokládejme, že bean TravelAgent je vytvořen a používán klientem následovně:

Propagace transakcí Transaction Propagation Metoda bookpassage() má transakční atribut RequiresNew v tomto případě, klient, který vyvolá bookpassage() není součástí transakce. Když je bookpassage() vyvolána TravelAgent beanem, je vytvořena nová transakce. To znamená, že bean TravelAgent se registruje u transakčního manažéra, který bude řídit transakci automaticky. 47

Propagace transakcí Transaction Propagation Když je vyvolána metoda creditby() uvnitř metody bookpassage(), bean ProcessPayment se registruje u transakčního manažera pod transakčním kontextem, který byl vytvořen pro bean TravelAgent; transakční kontext je šířený k beanu ProcessPayment. 48

Řízení transakčního kontextu TravelAgent beanu Client Application 1 Invoke bookpassage() 7 RequiresNew TravelAgent EJB Invoke bycredit() Required Process- Payment EJB Required 8 Register the ProcessPayment EJB 2 Register the TravelAgent EJB 4 Invoke EntityManager.persist() (reservation) Persistence context 5 Register the Reservation entity Check the Transaction ContextX to make sure that updates to each will work 10 Transaction Manager 3 Create a new Transactional Context called X. Add the TravelAgent EJB to X. TransactionalContext X TravelAgent EJB Reservation entity ProcessPayment EJB 6 9 Add the Reservation entity to X Add the ProcessPayment EJB to X 11 Commit all updates or roll back all updates 49

Zámky databáze Read locks zámek zabraňuje jiným transakcím měnit čtená data, dokud transakce neskončí; jiné transakce mohou data takéčíst; Write locks zámek zabraňuje jiným transakcím měnit data dokud daná transakce neskončí; naopak dovoluje jim dirty read Exclusine write locks zámak zabraňuje jiným transakcím číst nebo měnit data, dokud transakce neskončí; zabraňuje dirty read 50

Zámky databáze Snapshots je to zamrzlý pohled na data, který je proveden při začátku transakce. 51

Izolace transakcí Izolace zabezpečuje, že souběžní (concurrent) uživatelé jsou izolováni jeden od druhého, i když pracují se stejnou databází. K zabezpečení izolace se používářada zámků (locks). 52

Izolační úrovně Existujíčtyři transakční izolační úrovně: Mód READ UNCOMMITTED žádná garantovaná izolace, nejrychlejší provedení Mód READ COMMITTED řeší problém tzv. dirty read. Mód REPEATABLE READ řeší předchozí problém a problém tzv. unrepeatable read. Mód SERIALIZABLE řeší předchozí problém a problém phantom. 53

Problém Dirty Read Dirty problem aplikace čte data z databáze, která ještě nebyla committed ke zdroji. 1. Čtete X z databáze. Aktuálně X=0. 2. Přičtete 10 k X a uložíte do DB. X=10, ale neproběhl commit. 3. Jiná aplikace načte X (X=10). 4. Zrušíte transakci X=0. 5. Jiná aplikace přičte 10 k X a uloží do databáze, kde X=20?? 54

Mód READ UNCOMMITTED Dirty read nastává v tomto módu. Je nevhodné používat tento izolační mód při zpracování citlivých kalkulací jako bankovních účtů. Použití jen za předpokladu samostatného běhu instance dané komponenty. Výhoda rychlost provedení, nejsou potřebné žádné zámky. 55

Mód READ COMMITTED Kód bude číst pouze data, která jsou již committed. Nikdy se nebudou číst data, která byla zapsaná do databáze, ale nejsou committed. Výhodné použití pro čtení dat z DB pro reporting values. Výkonnost je pomalejší než u READ UNCOMMITTED z důvodů dalšího zámku. 56

Problém neopakovatelného čtení Unrepeatable Read Problem Problém při opakovaném čtení jsou data změněna. Např. 1. Načtete X z databáze. 2. Jiná aplikace data a nastaví X na jinou hodnotu. 3. Opakovaně načtete X hodnota je změněna. 57

Mód opakovaného čtení REPEATABLE READ garantuje ještě další vlastnost navíc od READ COMMITTED módu: kdykoli budete číst committed data opakovaně, jejich hodnota bude vždy stejná. Využití při aktualizaci jednoho nebo více datových prvků ve zdroji jako např. jeden nebo více záznamů v relační databázi. Potřebujete číst a aktualizovat každý řádek s vědomím, že nikdo jiný k nim souběžně nepřistupuje. 58

Fantomův problém Phantom Problem Phantom je nová množina dat, která se v databázi objeví během dvou operacíčtení. Např. 1. Vaše aplikace se dotazuje v databázi pomocí kritéria a získá množinu dat. 2. Další aplikace vloží nová data vyhovující výběrovému kritériu. 3. Provedete opakovaný výběr a množina vybraných dat je změněna. 59

Mód Serializable Mód je nejpřísnější izolací. Garantuje, že transakce vykonávané za sebou s ohledem jedna ke druhé budou nezávislé na ostatních. 60

Návrh transakčních konverzí v EJB Neúspěšné transakce automaticky vyvolají návrat na bod před transakcí (aktualizací), ale aktualizace DB je pouze polovina akce. Druhou polovinu tvoří kód aplikace, která se musí vypořádat s dopady transakce. Pro bezstavové session beany je zrušení business procesu jednoduchá úloha vyhodí výjimku zpět ke klientovi. Stavové session beany reprezentují proces, který překrývářadu volání metod a proto má v paměti konverzační stav. 61

Návrh transakčních konverzí v EJB Naštěstí dobře navržený stavový session bean může, v případě neúspěšné transakce, zachránit svůj konverzační stav. Klíčem je navrhnout beany tak, aby si uvědomovaly změny v konverzačním stavu a byly schopné undo operace v případě neúspěšné transakce. Tato činnost je však příliš aplikačně závislá, než aby to dělal aplikační server za vás. Aplikační server pomůže pouze při stanovení, kdy byla transakce neúspěšná. 62

Návrh transakčních konverzí v EJB Třída stavového session beanu musí proto implementovat volitelné rozhraní javax.ejb.sessionsynchronization s následujícím kódem: public interface javax.ejb.sessionsynchronization { public void afterbegin(); public void beforecompletion(); public void aftercompletion(); } 63

Návrh transakčních konverzí v EJB Uvedené metody je třeba implementovat a kontejner je bude vyvolávat v případě neúspěchu. afterbegin() je vyvolána kontejnerem přímo po začátku transakce. beforecompletion() je vyvolaná kontejnerem bezprostředně před ukončením transakce. aftercompletion() je vyvolaná kontejnerem přímo po ukončení transakce. Nejdůležitější bývá metoda aftercompletion(). Kontejner ji vyvolá vždy ať již po commit nebo abort. 64

Návrh transakčních konverzí v EJB Metoda aftercompletion() má parametr boolean, kterým je možné rozřešit, zda transakce byla úspěšnáči nikoli true - úspěšná 65