Vlákno názorů k článku Transakce a izolace transakcí v databázích od Lael Ophir - Pěkně napsané, i když tohle by měl znát...

Pěkně napsané, i když tohle by měl znát každý absolvent. Jen z hlediska konzistence výkladu bych doporučil použít příklad s aktivy a pasivy i pro vysvětlení rozdílu mezi READ UNCOMMITED a READ COMMITED. Také bych více rozvedl vysvětlení, proč je v konkrétním případě výsledek výběru neočekávaný.

Tak šup sem s tím, když to víš. Tož se poděl.
Už se klepu :-)

Nepochopil jste článek? Zkusme to znovu, třeba to půjde.

Provádíme následující dotaz:

BEGIN
SELECT sum(castka) FROM aktiva;
SELECT sum(castka) FROM pasiva;
COMMIT

Zároveň na serveru probíhá vkládání dat tímto způsobem (předpokládáme vždy shodu částek jdoucích na aktiva a pasiva):

BEGIN
INSERT INTO aktiva (castka) VALUES (1234)
INSERT INTO pasiva (castka) VALUES (1234)
COMMIT

Při úrovni izolace READ UNCOMMITED "vidí" SELECT i data z neuzavřených transakcí. Proto se může stát, že uvidíte vloženo těch 1234 v tabulce aktiva, ale ještě nebude totéž vloženo do tabulky pasiva. Pozmínka: také se může stát, že transakce měnící obsah tabulky neskončí potvrzením (COMMIT) ale zrušením (ROLLBACK), a vy jste data přesto uviděl a načetl. To bývá také nežádoucí.

Při úrovni izolace READ COMMITED vidíte jen data z potvrzených (commited) transakcí. Proto bude součet aktiv a pasiv vždy stejný. Problém je vyřešen. Jenže... Naše transakce se SELECTy provádí čtení dvěma dotazy. Může to dost dobře dopadnout to takhle:
1. prvním SELECTem vypočtete sumu z tabulky aktiva (a suma z tabulky pasiva bude v tu chvíli stejná)
2. pak někdo jinou transakcí aktualizuje tabulky aktiva i pasiva
3. Vypočtete sumu z tabulky pasiva, ale už tam budete mít započtené změny učiněné v kroku 2. Aktiva v tuhle chvíli budou opět sedět s pasivy, ovšem hodnoty už budou dávno odlišné. Oops, pořád máme problém.

Co s tím? Naštěstí tu máme úroveň izolace SERIALIZABLE. Na téhle úrovni izolace se DB tváří, jako kdyby byla vždy vykonána celá transakce, a teprve poté začala další transakce (což řeší náš problém popsaný v u READ COMMITED).
Typická implementace úrovně SERIALIZABLE vypadá tak, že (navíc proti nižším úrovním izolace) transakce provádíte najednou, ale při čtení si zamknete záznamy v DB. Když se je pak někdo snaží změnit, jeho transakce musí čekat, dokud není zámek odstraněn. Pokud transakce na zámek nenarazí, může být uskutečněna. Asi není třeba říkat, že práce se zámky je pro dospělou DB s hromadami transakcí probíhajících v jednom čase klíčovou záležitostí.

Mohli bychom si povídat ještě o snapshotech (verzování polí DB a řešení konfliktů až při commitu), příčinách a řešeních deadlocků (třeba wait-for graph), třífázovém commitu (používá se v heterogenních a distribuovaných systémech), a spoustě dalších krásných věcí. Jenže na to nemám čas, a navíc je sdílení vědomostí obtížné a nevděčné.

Pro vaši informaci teoretické základy pro vznik RDBMS byly položeny Edgarem Coddem někdy v sedmdesátých letech, a implementace se začaly šířit v letech osmdesátých. Na začátku Coddova práce mohla působit jako neškodná akademická hříčka. Dnes na ní stojí veliký kus IT světa.

Pokud chcete více informací, sežeňte si dokumentaci k MS SQL Serveru. Koncepty jsou tam vysvětlené tak, že to musí být jasné i slepému. Alternativou jsou skripta, wikipedia nebo učebnice.

seda je teorie, zeleny je strom zivota ... co si z te Vasi teorie mame odnest do toho zivota ?

Pokud je to pro vás obsah článku nebo mého příspěvku novinka, tak se zkuste naučit nejdůležitější teoretické základy, než se pustíte do praktických realizací. Vzdělání pomůže, ale není nutné; informace jsou k dispozici všude po webu, a mozek máte vlastní.

IT je svým způsobem řemeslo, a jako ostatní řemesla zaslouží kvalitní provedení. Co byste si myslel o instalatérovi, který nezná základy svého řemesla? A co si myslíte o člověku, který bez znalosti základů svého řemesla špatně navrhne DB (porušení normálních forem), a/nebo špatně navrhne aplikaci (s race conditions), a/nebo aplikaci napíše nebezpečně (umožní SQL injection)? Takový člověk dělá ostudu sobě i celému odvětví, a ještě často způsobí škody.

"Na začátku Coddova práce mohla působit jako neškodná akademická hříčka. Dnes na ní stojí veliký kus IT světa."

Spíš bych řekl, že veliký kus světa stojí nad zpotvořeninou Coddovy práce. Přečtěte si Třetí manifest od Datea a Darwena a pochopíte.

Codd položil základ DB, a jeho teorie byla do praxe převedena celkem dobře. Tedy na úrovni DB. Integrace mezi DB a objektovým prostředím je věc jiná. Tady je třeba přiznat, že to tak úplně nevyšlo. Ale znáte to - I consider my glass half full ;)