LINUXSOFT.cz Přeskoč levou lištu
Uživatel: Heslo:  
   CZUKPL

> PostgreSQL (16) - Zamykání

Tento díl bude věnován zámkům tabulek, což je další nástroj k udržení konzistence dat, jejich možnostem a konfliktům.

22.9.2005 06:00 | MaReK Olšavský | Články autora | přečteno 14831×

Při transakčním zpracování dat provádí PgSQL server zamykání řádků a tabulek automaticky. Nastartovaná transakce zamkne řádky tabulek, na nichž probíhají aktivní operace, jako například UPDATE a DELETE, po dobu svého trvání, aby dvě se konkurenční operace nepokoušely měnit data v tabulce, přičemž jedna z nich by aktualizovala data, která již nejsou platná. Pokud je nastartována jedna transakce, která provádí aktivní operace a za jejího běhu je spuštěna transakce druhá, tak ta bude čekat, dokud nebudou z první transakce uvolněny řádky, na kterých se při aktivní operaci "potkaly", ať už potvrzením (COMMIT), nebo zamítnutím (ROLLBACK). Výjimka z tohoto chování je úroveň SERIALIZABLE, která by ukončení druhé transakce vrátilo jako nepotvrzené v momentě potvrzení transakce první.

Zamykání řádek se týká pouze aktivních operací. Aplikace/vlákno téže aplikace na SQL příkaz SELECT dostane požadovaná data, podle zapnutého transakčního módu probíhající transakce, buď ta potvrzená, nebo i ta, která ještě nebyla potvrzena.

V případě, že je třeba společně se SELECTem řádek zamknout proti změnám, například je nutné vybrat aktuální data zaměstnance, ta upravit a poslat zpět na server, přičemž je nežádoucí, aby někdo jiný mezitím mohl tato data modifikovat (tento případ může nastat, když má personalistiku ve firmě na starosti několik pracovníků), je možné použít modifikaci příkazu SELECT doplněnou o klauzuli FOR UPDATE. Postup by tedy mohl být následující:

BEGIN
SELECT * FROM employees WHERE pid = 562 FOR UPDATE;
-- v programu jsou zmenena data, ostatni je
-- mohou poze cist, nikoliv menit, nebo mazat
UPDATE employees SET (... hodnoty ...) WHERE pid = 562;
COMMIT;
-- v pripade chyby ROLLBACK

Pokud by nastala chyba, například by spadl databázový server, nebo bylo přerušené spojení mezi databází a programem, je transakce automaticky zrušena.

Dosud bylo psáno o zamykání jen na úrovni řádek, tak jak je řeší automaticky PostgreSQL server. Samozřejmě, že server může v případě potřeby zamknout i celou tabulku, například při příkazu pro změnu tabulky ALTER TABLE (příkaz ALTER bude probírán až malinko později).

Implicitní zamykání, o kterém byla tato kapitola není pro programátora, pracujícího s PostgreSQL serverem až tak moc zajímavá, protože jí řeší víceméně server sám. Mnohem  zajímavější je explicitní zamykání, kdy vývojář sám určuje, které tabulky/řádky a jak budou zamčeny.

Explicitní zamykání

Podobně, jako u transakcí, je i u zamykání několik módů, které se liší tím, co dovolují a co nikoliv. Dříve, než bude probrán příkaz pro zamykání tabulek, který se jmenuje zcela intuitivně LOCK, je vhodné seznámit se s těmito módu.

Klíčovými slovy pro jednotlivé módy jsou:

  • EXCLUSIVE - Výlučný zámek, který nedovoluje zamknout kterékoliv jiné transakci, jinému příkazu, tabulku, nebo řádek. Tento mód zámku je dafaultní, tzn. není li uvedeno EXCLUSIVE, nebo SHARE, je použit tento druh zámku.
  • SHARE - Další  příkazy/transakce mohou sdílet tento zámek. Je-li tabulka/řádek zamknuta tímto zámkem, není možné jej "přebít" pomocí zámku EXCLUSIVE.
  • ROW - Uzamčení řádk(u/ů) tabulky.
  • TABLE - Uzamčení celé tabulky, nejvíce restriktivní, pokud jej PostgreSQL serveru nepřikážeme explicitně, tak ta jej použije jen velmi vyjímečně.
  • ACCESS - Zamčení schématu tabulky, tzn. že není možné měnit její strukturu

Jejich logické kombinace, respektive módy, které umí PgSQL a používá implicitně, jsou uvedeny v následujícím výčtu, včetně možných konfliktů:

  • ACCES SHARE - Mód pro příkazy, které nepracují aktivně s daty, mohou jej získat například příkazy SELECT a ANALYZE (ten bude probrán později). Nejméně omezující mód, zabraňuje změně tabulky příkazy ALTER TABLE, DROP TABLE a VACUUM
    • Tento mód se vyločuje se souběhem ACCESS
  • ROW SHARE - Mód, ve kterém si zamyká řádky příkaz SELECT ... FOR UPDATE. Pokud jde o nějaký kombinovaný SELECT, tak všechny, které nejsou označeny jako FOR UPDATE si PgSQL server zamkne v ACCESS SHARE módu. Tento mód lze příkazem povýšit na ROW EXCLUSIVE
    • Vylučuje se s módy EXCLUSIVE a ACCESS EXCLUSIVE
  • ROW EXCLUSIVE - V tomto módu si zamykají řádky příkazy, které provádí aktivní činnost nad daty, tj. UPDATE, DELETE a INSERT. Změna struktury rad je mnohem více restriktivní. Pokud je s těmito příkazy spjat nějaký SELECT jsou řádky tohoto SELECTU uzamčeny jen jako ACCESS SHARE.
    • Konflikt s SHARE, SHARE ROW EXCLUSIVE, EXCLUSIVE a ACCESS EXCLUSIVE.
  • SHARE UPDATE EXCLUSIVE - Používá jej příkaz VACUUM (opět bude probrán později)
    • Konflikt s módy SHARE UPDATE EXCLUSIVE, SHARE, SHARE ROW EXCLUSIVE, EXCLUSIVE a ACCESS EXCLUSIVE
  • SHARE - Data lze číst i zapisovat (jen je tím značně ztížena operace, která si tento zámek vytváří), tento zámek si dělá PgSQL při vytváření indexů. Jedná se o sdílené uzamčení celé tabulky, čiže opět jsou blokováný příkazy ALTER TABLE, DROP TABLE a VACUUM.
    • Konflikty: ROW EXCLUSIVE, SHARE UPDATE EXCLUSIVE, SHARE ROW EXCLUSIVE, EXCLUSIVE a ACCESS EXCLUSIVE.
  • SHARE ROW EXCLUSIVE - Server tento mód nepoužívá automaticky. Blokuje souběžné dotazy SELECT ... FOR UPDATE, tj. zámek ROW SHARE.
    • Konflikty: ROW EXCLUSIVE, SHARE UPDATE EXCLUSIVE, SHARE, SHARE ROW EXCLUSIVE, EXCLUSIVE a ACCESS EXCLUSIVE
  • ACCESS EXCLUSIVE - Je automaticky použit při ALTER TABLE, DROP TABLE a VACUUM. Nejvíce omezující režim, který nedovolí jakékoliv souběžné operace na tabulce
    • Vylučuje se se všemi ostatními módy.
  • EXCLUSIVE - Blokuje na celé tabulce stejné dotazy, jako SHARE ROW EXCLUSIVE. Na tabulce je povolené pouze čtení.
    • Vylučuje se s  ROW SHARE, ROW EXCLUSIVE, SHARE UPDATE EXCLUSIVE, SHARE, SHARE ROW EXCLUSIVE, EXCLUSIVE a ACCESS EXCLUSIVE.

Zámek se na tabulce uplatňuje pomocí příkazu: LOCK TABLE jmeno_tabulky [, dalsi_tabulky] [IN mod_zamceni MODE] [NOWAIT], kde mod_zamceni je jeden z výše jmenovaných a klauzule NOWAIT oznamuje, že pokus o uzamčení tabulky a tím i transakce budou ukončeny neúspěšně (ROLLBACK), když nebude možné okamžité požadované uzamčení tabulky (tabulek). Zámky tabulek se uvolňují ukončením transakcí, ať již úspěšným, nebo neúspěšným.

Pokud nebude explicitně vyjmenován mód uzamčení tabulky, server automaticky použije to nejpřísnější zamčení, tj. LOCK TABLE tabulka IN ACCESS EXCLUSIVE MODE NOWAIT.

Automatické zamykání tabulek lze většinou ponechat bez toho, že bude z programu, který PgSQL používá, jakkoliv měněno. Může být ale velikou pomocí, když je třeba tato pravidla pro určité operace zpřísnit, například při postupném čtení velkého množství dat, kdy je nežádoucí, aby někdo změnil data, která již byla načtena. Přesně k tomuto slouží příkaz LOCK.

Deadlock

V případě velkého provozu na databázi (například při souběžném připojení velikého počtu klientských aplikací) lze narazit na stav, kdy dvě transakce budou vzájemně čekat na výsledek té druhé (1. transakce ke svému dokončení potřebuje výsledek z první a naopak), který se označuje jako Deadlock. Systém automaticky jednu z těchto transakcí vrátí (ROLLBACK), protože tyto by jinak mohli čekat do nekonečna. Tomuto stavu lze předejít díky zámkům. PgSQL server má většinu zámků u konkurenčních databází konfliktních, což znamená, že zamkne-li se z aplikace tabulka, nebo řádek, a z jiného klienta je použit zámek, který je konfliktní s tím současným, je tato transakce odmítnuta. Pouhým pohledem do tabulky módů zámků lze najít autokonfliktní zámky (tj. jsou v konfliktu sami se sebou), což znamená, že je výhodné je použít. Pokud není možné použít zamčení na stejný typ zámků, bylo by výhodné zajistit, aby nejdříve byly uplatněny ty nejpřísnější zámky z požadovaných.

V praxi k deadlocku téměř nemůže dojít, protože PgSQL server nejméně jednu transakci zruší, kdyby se do tohoto stavu dostal, aby těm ostatním umožnil doběhnout.

Tip

Pro otestování toho, jak fungují transakce a zámky není třeba psát složitou aplikaci, stačí se přes několik terminálů přihlásit k PgSQL, na nich nastartovat transakce a v nich zkoušet konfliktní chování příkazů, tj. včetně toho, co Vám server dovolí a co nikolivěk.

Závěrem

Cílem tohoto dílu bylo představit zamykání tabulek a řádků, které v těsném závěsu za transakcemi "zaručuje" konzistenci vkládaných dat. Bohužel ani tento mechanismus není dokonalý a pokud se vyskytne uživatel, který bude mít snahu, byť nezáměrnou, vložit do databáze nesmysly a bude tato snaha kombinována s nedostatečně předvídavým programátorem, bude v datech chaos plný nesmyslů, díky transakcím, alespoň konzistentní.

Mechanismus transakcí a zámků umí většina databázových serverů, včetně, především mezi webaři, široce používaného MySQL, byť to neumí transakce na svých přirozených tabulkách, ale o tomto serveru je na portále LinuxSoft.cz "sesterský" seriál, kde tato problematika též bude probrána. Zámky MySQL také umí, ale nemají tak široké možnosti a není zase tak obtížné zamknout tabulku mimo transakci a tato tabulka pak může zůstat zamčená téměř donekonečna, tj. nejméně do doby, než ji administrátor odemkne.

Tímto dílem seriálu je ukončena první logická část seriálu, ve které bylo především cílem naučit čtenáře, jak vytvořit databázi, vložit do ní data, ta umět vybírat, měnit, eventuálně mazat, zpracovat je jednoduše pomocí vestavěných funkcí, databázi urychlit pomocí indexů a naučit se pomocí transakcí udržet konzistentní data, kdy při aktivních operacích se provádí několik souvisejících příkazů. Od dalšího dílu budou již probírána malinko pokročilejší témata, která již nemusí být potřebná pro základní a jednoduché používání PostgreSQL serveru.

Verze pro tisk

pridej.cz

 

DISKUZE

instalace PostgreSQL 3.10.2005 11:10 Jiří Zelinka
  L Re: instalace PostgreSQL 3.10.2005 12:17 Ondřej Čečák
    L Re: instalace PostgreSQL 3.10.2005 12:22 Jiří Zelinka
      L Re: instalace PostgreSQL 7.10.2005 16:42 mr.builder




Příspívat do diskuze mohou pouze registrovaní uživatelé.
> Vyhledávání software
> Vyhledávání článků

14.11.2017 16:56 /František Kučera

Máš rád svobodný software a hardware nebo se o nich chceš něco dozvědět? Zajímá tě DIY, CNC, SDR nebo morseovka? Přijď na sraz spolku OpenAlt – tradičně první čtvrtek před třetím pátkem v měsíci: 16. listopadu od 18:00 v Radegastovně Perón (Stroupežnického 20, Praha 5).


Přidat komentář

12.11.2017 11:06 /Redakce Linuxsoft.cz
PR: 4. ročník odborné IT konference na téma Datová centra pro business proběhne již ve čtvrtek 23. listopadu 2017 v konferenčním centru Vavruška, v paláci Charitas, Karlovo náměstí 5, Praha 2 (u metra Karlovo náměstí) od 9:00. Konference o návrhu, budování, správě a efektivním využívání datových center nabídne odpovědi na aktuální a často řešené otázky, např Jaké jsou aktuální trendy v oblasti datových center a jak je využít pro vlastní prospěch? Jak zajistit pro firmu či jinou organizaci odpovídající služby datových center? Podle jakých kritérií vybrat dodavatele služeb? Jak volit součásti infrastruktury při budování či rozšiřování vlastního datového centra? Jak efektivně spravovat datové centrum? Jak eliminovat možná rizika? apod.
Přidat komentář

13.9.2017 8:00 /František Kučera
Máš rád svobodný software a hardware nebo se o nich chceš něco dozvědět? Zajímá tě DIY, CNC, SDR nebo morseovka? Přijď na sraz spolku OpenAlt – tentokrát netradičně v pondělí: 18. září od 18:00 v Radegastovně Perón (Stroupežnického 20, Praha 5).
Přidat komentář

3.9.2017 20:45 /Redakce Linuxsoft.cz
PR: Dne 21. září 2017 proběhne v Praze konference "Mobilní řešení pro business". Hlavní tématy konference budou: nejnovější trendy v oblasti mobilních řešení pro firmy, efektivní využití mobilních zařízení, bezpečnostní rizika a řešení pro jejich omezení, správa mobilních zařízení ve firmách a další.
Přidat komentář

15.5.2017 23:50 /František Kučera
Máš rád svobodný software a hardware nebo se o nich chceš něco dozvědět? Zajímá tě DIY, CNC, SDR nebo morseovka? Přijď na sraz spolku OpenAlt, který se bude konat ve čtvrtek 18. května od 18:00 v Radegastovně Perón (Stroupežnického 20, Praha 5).
Přidat komentář

12.5.2017 16:42 /Honza Javorek
PyCon CZ, česká konference o programovacím jazyce Python, se po dvou úspěšných ročnících v Brně bude letos konat v Praze, a to 8. až 10. června. Na konferenci letos zavítá např. i Armin Ronacher, známý především jako autor frameworku Flask, šablon Jinja2/Twig, a dalších projektů. Těšit se můžete na přednášky o datové analytice, tvorbě webu, testování, tvorbě API, učení a mentorování programování, přednášky o rozvoji komunity, o použití Pythonu ve vědě nebo k ovládání nejrůznějších zařízení (MicroPython). Na vlastní prsty si můžete na workshopech vyzkoušet postavit Pythonem ovládaného robota, naučit se učit šestileté děti programovat, efektivně testovat nebo si v Pythonu pohrát s kartografickým materiálem. Kupujte lístky, dokud jsou.
Přidat komentář

2.5.2017 9:20 /Eva Rázgová
Putovní konference československé Drupal komunity "DrupalCamp Československo" se tentokrát koná 27. 5.2017 na VUT FIT v Brně. Můžete načerpat a vyměnit si zkušenosti z oblasti Drupalu 7 a 8, UX, SEO, managementu týmového vývoje, využití Dockeru pro Drupal a dalších. Vítáni jsou nováčci i experti. Akci pořádají Slovenská Drupal Asociácia a česká Asociace pro Drupal. Registrace na webu .
Přidat komentář

1.5.2017 20:31 /Pavel `Goldenfish' Kysilka
PR: 25.5.2017 proběhne v Praze konference na téma Firemní informační systémy. Hlavními tématy jsou: Informační systémy s vlastní inteligencí, efektivní práce s dokumenty, mobilní přístup k datům nebo využívání cloudu.
Přidat komentář

   Více ...   Přidat zprávičku

> Poslední diskuze

18.9.2017 14:37 / Rojas
high security vault

15.9.2017 7:33 / Wilson
new zealand childcare jobs

31.8.2017 12:11 / Jaromir Obr
Re: ukůládání dat ze souboru

30.7.2017 11:12 / Jaromir Obr
Národní znaky

27.7.2017 12:24 / Jaromir Obr
Cteni/zapis

Více ...

ISSN 1801-3805 | Provozovatel: Pavel Kysilka, IČ: 72868490 (2003-2017) | mail at linuxsoft dot cz | Design: www.megadesign.cz | Textová verze