K čemu slouží transakce

Při jakékoliv operaci může dojít k chybě při práci s daty, ať již pádem serverové služby, nebo špatně položeným dotazem. Teoreticky se při SELECTu tak mnoho neděje, jen aplikace nezíská všechna potřebná data, ale při zadávání nových záznamů, jejich změnách, či mazání by mohl nastat velmi závažný problém s integritou dat.

Modelový příklad může být změna změna cen v elektronickém obchodě, například z konkurenčních důvodů. Po zadání příkazu UPDATE products SET price = price / 1.01, což je zlevnění veškerého zboží o 1% může v chodu serveru nastat chyba, například při aktualizaci 1028 položky z 9000. Pokud nejsou použity transakce, bude aktualizováno právě těch prvních 1027 položek, ale další zůstanou neaktualizovány. Aplikace se dozví, že nastala chyba a pokusí se tuto aktualizaci spustit znovu, takže těch prvních 1027 položek bude 2x zlevněno o 1%. Dalo by se tomuto předejít použitím timestampu, kdy další pokus by aktualizoval data, která by měla starší (třeba o 1 hodinu) datum aktualizace, než je poslední timestamp.

Popisovaný příklad navíc nepočítá se změnami, které mohou probíhat na dalším připojení k databázi z aplikace spuštěné na jiném počítači. Například z jiného místa bude změněn popis zboží, čiže timestamp by mohl nasvědčovat tomu, že cena již byla aktualizována byla.

Tyto problémy se řeší jednodušeji, než se zdá, pomocí tzv. transakčního zpracování, které je sice o malinko pomalejší, ale odolná vůči těmto problémům. Transakce v podstatě zajišťují, že pokud není příkaz provedený do konce korektně a není tudíž potvrzen, nejsu změny přístupné v následujících příkladech. V příkladě, který byl napsán o několik řádků výše to znamená, že pokud nastane chyba, když bude mechanismus db serveru aktualizovat 1028 řádek, tak nebude uloženo ani těch prvních 1027 řádek se změněnou cenou.

Každý příkaz, který je odeslán na PostgreSQL server je "obalen" v samostatné transakci, a pracuje nad obrazem dat, který byl k dispozici v momentě zahájení transakce. Trochu problém by mohl nastat pokud by měnění dat bylo prováděno z vícero míst současně, protože by server nemusel být schopen sestavit správně všechny změny, které byly zadány, takže v tomto místě k transakcím ještě přistoupí zamykání tabulek, se kterými se seznámíme v příštím díle.

Transakční módy a módy čtení

PostgreSQL server nabízí několik módů, ve kterých může data zpracovávat v transakcích (pro ty jsou módy 4) a další 3 módy pro čtení.

Módy transakcí:

• READ COMMITTED - Základní mód PgSQL, kdy dotaz čte pouze data z ukončených/potvrzených transakcí. Pokud během čtení je některá z transakcí ukládajících, či měnících, data potvrzena, tento SELECT je neuvidí.
• READ UNCOMMITTED - Chová se stejně, jako READ COMMITED, je zde jen z důvodu kompatibility s SQL standardem. V původní verzi má číst i data, která ještě nemají potvrzené transakce (v případě nepotvrzeného DELETE jsou vynechány řádky, které mají být vymazány).
• SERIALIZABLE - Nejčistší a nejbezpečnější forma transakčního zpracování. Server nepovolí paralelně přes sebe běžící transakce, ale řadí jednu za druhou. V tomto módu je nutné mít aplikaci připravenu na opakování transakce (bloku příkazů), když bude serverem změna zamítnuta.
• REPEATABLE READ - V PgSQL má stejné chování, jako SERIALIZABLE, je opět pouze kvůli kompatibilitě s SQL std. V normované verzi příkaz SELECT zpracuje a vrátí aplikaci pouze data, která jsou potvrzená, přičemž, ale doběhne-li některá transakce měnící data, je tento blok znovu SELECTEM zpracován a zařazen do návratových dat.

Módy čtení:

• DIRTY READ - Transakce čte data, která nejsou ještě potvrzená v jiné transakci.
• NONREPEATABLE READ - Transakce znovu načte data, která byla načtena při prvním čtení z tabulky a najde data, která byla mezitím potvrzena z jiné transakce.
• PHANTOM READ - Transakce znovu vykonná dotaz vracející množinu řádek odpovídající vyhledávací podmínce a najde řádky, které byly mezitím z jiné transakce potvrzeny, jako zpracované.

Aby vše nebylo úplně jednoduché, není možné kombinovat módy transakcí s módy čtení kombinovat zcela libovolně, ale PgSQL si tuto režii, který mód bude použit zařizuje sám, jen na základě nastaveného transakčního módo. Tabulka, z originální dokumentace, ukazuje, které módy transakcí a čtení nesmí být zkombinovány a z těch povolených je už jen na serveru, který použije.

Seskupení příkazů do transakce

PostgreSQL server pracuje v tzv. Autocommit  módu, kdy každý příkaz je "obalen" ve své vlastní transakci, čímž je předejíto možnosti chyb, která byla naznačena v modelovém příkladě. V řadě případů je nutné mít explicitně v jedné transakci několik SQL příkazů. K tomu slouží pár příkazů BEGIN a END, kterými se blok příkazů obalí.

Příkaz BEGIN má několik doplňkových parametrů, čiže jeho výsledný tvar má následující možnosti: BEGIN [WORK | TRANSACTION] [ISOLATION LEVEL transaction_mode [, ...]], kde klíčová slova WORK a TRANSACTION jsou volitelné parametry, které jsou bezvýznamové, ale v souladu s normou, pokud je transakce započata například, jako WORK, musí být takto i ukončena. Parametr transaction_mode má některou z hodnot READ COMMITTED, READ UNCOMMITTED, SERIALIZABLE a REPEATABLE READ, které byly vysvětleny v předchozí kapitolce, další volitelné prarametry, které jsou spjaty s ISOLATION LEVEL transaction_mode a jsou volitelné jsou READ ONLY a WRITE ONLY, které určují, pro kterou část práce s daty patří v danné transakci mód. Ekvivalentem tohoto příkazu, včetně stejných parametrů, jen neobsahující jedno z dvojice klíčových slov WORK a TREANSTACTION.

Pro ukončení transakce jsou k dispozici 2 příkazy, jeden pro potvrzení transakce, který se jmenuje COMMIT [WORK | TRANSACTION] a druhý je ROLLBACK [WORK | TRANSACTION], který slouží pro zrušení transakce, tudíž veškeré změny jsou zahozeny. Tyto příkazy jsou posílány z aplikace, takže není problém kdykoliv v průběhu práce s daty, nebo při chybě odchycené v aplikaci, transakci zrušit. Pro vysvětlení: při nastartování transakce z aplikace, a zadávání dalších příkazů z této, server standardně reaguje například na chybně zadaná data (řetězec do čísla, ...), takže chyba je oznámena standardním mechanismem aplikaci, tudíž je možné na ní zareagovat, například zrušením transakce.

Užitečnou vlastností při používání transakcí je možnost vytvořit si návratové body, tzv. SAVEPOINTs. Vytvářejí se klíčovým slovem SAVEPOINT jmeno, kde jméno savepointu je plně v rukou programátora a je povinným parametrem. Pro zrušení všech změn (rollback), které se udály mezi nastavením návratového bodu a se používá příkaz ROLLBACK TO SAVEPOINT jmeno, přičemž transakce zůstane běžící, jen jsou zrušeny změny k tomuto návratovému bodu. Pokud je v aplikaci návratový bod již nepotřebný, lze jej zrušit příkazem RELEASE SAVEPOINT jmeno.

Kromě výše uvedených příkazů lze pro všechny operace používat "centrální" nastavení vlastností transakcí příkazem SET TRANSACTION transaction_mode [, ...], kde transaction_mode je jeden z módů, uvedených v předchozí kapitolce a je možný přídavný parametr READ ONLY, nebo WRITE ONLY, jehož význam je stejný, jako u BEGIN/START TRANSACTION. Tímto příkazem se nastaví transakce pro jedno sezení, poté je stačí pouze startovat a ukončovat. Pokud je tento příkaz odeslán při již otevřené/spuštěné transakci, nemá žádný vliv na její průběh.

Dodatky k transakcím

Transakce, tak jak je nabízí PgSQL nejsou ekvivalentní k možnostem, které má MySQL, dokonce ta je nemá na svých MyISAM tabulkách, ale je třeba použít InnoDB tabulky. V MySQL znamená přechod na InnoDB tabulky dokonce zpomalení celé databáze, bohužel.

Byť je režie transakcí pro databázi zpomalující, může být soustředění několika příkazů do jedné transakce přínosné pro výkon databáze jako takové, vůči stavu bez jejich použití. Jak bylo napsáno, PgSQL pracuje v tzv. Autocommit módu, tj. je-li na server posláno několik nesouvisejících příkazů (čiže logicky by nebylo třeba je obalovat startem a ukončením transakcí), jsou tyto vykonávány jeden za druhým s tím, že pro každý extra je otevírána a potvrzována transakce, ale v případě že je explicitně nastartována transakce, jsou vykonány všechny změny, které jsou do ní promítnuty teprve po jejím potvrzení.

Transakce přináší také vyšší nároky na diskový prostor. V případě, že má databáze 800 MB a příkazy seskládanými v transakci bude ovlivněno 500MB, je třeba mít volných těchto 500MB v paměťovém/diskovém prostoru serveru.

--Jednoduse nastartovana a potvrzena transakce
BEGIN TRANSACTION ISOLATION LEVEL READ COMMITTED;
UPDATE products SET unitprice = unitprice / 1.01;
DELETE FROM products WHERE unitprice<5.00;
COMMIT TRANSACTION

--Nastartovana a zamitnuta transakce
START TRANSACTION ISOLATION LEVEL READ COMMITTED;
UPDATE products SET unitprice = unitprice / 1.01;
DELETE FROM products WHERE unitprice>1000.00;
ROLLBACK TRANSACTION

--Pouziti savepointu
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
START TRANSACTION;
SAVEPOINT muj_navrat;
UPDATE products SET unitprice = unitprice * 2;
ROLLBACK TO SAVEPOINT muj_navrat;
SAVEPOINT muj_navrat;
UPDATE products SET unitprice = unitprice * 1.02;
RELEASE SAVEPOINT muj_navrat;
DELETE FROM products WHERE unitprice>1000.00;
ROLLBACK TRANSACTION;

Tyto příklady jsou jen na to, jak mohou být příkazy za sebou seskládány, ale většinou budou tyto posílány z aplikace, čiže bude možná interakce s chybami, které vrátí PgSQL server do aplikace, případně reakce na chyby uživatele aplikace při změnách dat.

Závěrem

Cílem tohoto dílu bylo seznámit se s transakcemi a jejich použitím. V příštím díle bude probráno zamykání tabulek, čímž lze dopomoci k vyšší úrovni integrity dat.