Dotaz: Časové zamykání řádků tabulky - PostgreSQL

[pools]

Ahoj, řeším teď takový problém se zamykáním tabulky. Píšu jednu webovou aplikaci a potřebuju aby uživatel který edituje jeden objekt při načtení dat zamkl současně tabulku - to by nebyl problém, nevím však, jak to vyřešit, když data zpět neuloží -> a tím pádem tabulku zase neodemkne. Nevíte někdo jestli neexistuje něco jako nastavení času platnosti zámku v Postgresu? Aby třeba platil pouze patnact minut a pak se řádek automaticky odemknul? Nedokázal jsem k tomu na netu nic najít... Díky

---

---

Odpovědi

[Josef Kufner]

Přidej do té tabulky dva sloupce, kde bude čas budoucího odemknutí a ID uživatele, který to zamknul. Pak stačí jen kontrolovat, zda čas budoucího odemknutí je v minulosti nebo NULL.

[pools]

No podobně to dělám doteď, ale myslel jsem spíše nějaký systémovější způsob jestli neexistuje...

[l0gik]

A proč zamyká celou tabulku? Něco máš imho špatně v designu - zamykat bys měl jen to, s čím pracuješ, ne celou tabulku.

Jinak SELECT blablabla FOR SHARE/UPDATE ti do konce transakce zamkne záznamy pro čtení/pro zápis (nikdo jiný je nebude moct měnit/ani přečíst). Nevím, jak zamykáš jinak, ale tendle zámek se po konci transakce odemkne automaticky.

[pools]

sorry, to byl překlep, zamykám samozřejmě jen editovaný řádek. ale co je podle tebe konec transakce u php skriptu? mi jde o to, zamknout řádek tabulky když načtu data do selectu, abych měl patnáct minut jistotu, že mi je nikdo nepřepíše, ale po této době i když nedám ten update aby se tabulka automaticky odemkla. a potřebuju aby šly nadále číst, jen se nesmí dostat k editaci...

[l0gik]

Konec transakce je příkaz COMMIT/ROLLBACK (popř. konec každého příkazu, pokud si nenastartoval transakci púomocí BEGIN).

[trekker.dk]

Záleží na tom, co přesně vlastně potřebuješ.

Jestli máš aplikaci, kde uživatel začne pracovat s nějakým objektem (tzn. načte stránku, něco se mu tam objeví, on do toho chvilku ťuká a píše a pak klikne, aby se uložilo), tak ti transakce nepomůžou a budeš muset udělat něco, co je hned v prvním příspěvku. Tzn. zamknout záznam něčím jako

UPDATE záznam SET cas_odemceni = now() + '15m'::interval, zamykatel = ID toho, kdo to zamkl WHERE id = ID objektu

Před pokusem objekt měnit se podíváš, jestli je zamykatel NULL (= záznam není zamčený). Když není NULL, porovnáš ID zamykatele s tím, kdo se snaží k objektu přistoupit (záznam je zamčený pro všechny ostatní.) Když ID nesouhlasí, porovnáš cas_odemceni s now() (jestliže je now() větší, záznam byl zamčen, ale zámek vypršel)

Pokud máš aplikaci, kde objekt musí být zamčený jenom v době, kdy s ním pracuje ten skript, použij transakce. To už popsal logik v #3 a #5, jenom doplním, že transakci ukončí i konec skriptu, tedy uzavření spojení do DB.

[dad]

tedy ja ma tak nejak zafixovano, ze vsechna tahle reseni maji radu much a to z velkou pravdepodobnosti 'nejrozumnejsi' je pouzit timestamp.

[l0gik]

No zamykání záznamů "dopředu" před editací moc dobrá technika není. Daleko lepší bývá to řešit revizema (při updatu si zkontroluju, jestli mi záznam někdo nezměnil pod rukama (zkontroluju číslo revize) a kdyžtak ho neupravím a místo toho sdělím uživateli problém).

[pools]

takže jako nechám uživatele aby vesele něco pět minut nastavoval a při uložení mu suše oznámíš: dělal jsi to na hovno? rozumím tomu dobře?

[FooBar]

Ocividne nerozumis, kdyz reagujes takhle agresivne na cloveka, kterej ti poskytuje (naprosto spravnou) radu.

RTFM: http://en.wikipedia.org/wiki/Optimistic_concurrency_control

Je to casto pouzivany reseni napr. na wiki, na zaklade predpokladu ze realne to tak moc lidi soubezne editovat nebude. Navic, vzhledem k tomu, ze je to human-readable, muzes pomerne trivialne nabidnout merge vuci novy revizi.

Optimistic concurrency control ma drahy konflikty (tim ze musis informovat uzivatele / resit merge), ale jinak je trivialni na implementaci a v pripade ze moc konfliktu nemas (coz je typicky pripad prave treba wiki), tak je i efektivnejsi.

[dad]

ja si myslim, ze tohle neni ta spravna odpoved. Aby byla situace jasnejsi, je treba se zeptat soudruha, jak bude reagovat on v tom pripade, ze zaznam je zamcen.

napise hlasku 'zkuste to ca. za 5 minut', nebo 'zkuste to pozdeji'? A jaka bude hlaska, az to uzivatel skutecne za nejaky cas znova zkusi a opet to bude zamcene?

[FooBar]

Nebo ostatne jaka bude reakce, kdyz bude mit zamek na v originalnim postu zminenych 15 minut, a clovek to holt bude editovat 16 minut... a nekdo jiny mu to pred ulozenim sebere pod rukama (a zamkne na dalsich 15 minut).

[Josef Kufner]

Tohle se řeší tak, že to nezamkneš na 15 minut, ale na pět (nebo i méňe) a javascriptem v pravidelných intervalech prodlužuješ zámek. Takže jakmile uživatel zavře okno nebo odejde jinam, tak zámek zmizí rychle a pokud edituje hodinu, tak to má hodinu zamčené. Pro případ, že by to jen nechal otevřené, tak je dobré koukat na stisky kláves a pokud se nic neděje, tak se dotázat, zda prodloužit (nějakým tichým způsobem, např. ukázat div s dotazem přes editor).

[pools]

Ale to co je v tom Optimistic concurrency control je podle toho co jsem přečetl úplně mimo oproti tomu na co jsem se ptal - já potřebuju vědět jestli to někdo edituje a nemůžu nikomu povolit aby editoval stejnou věc zároveň - mám data pro které to není relevantní. Ptal jsem se jasně jestli existuje způsob jaký popisuju v dotaze - očividně neexistuje, ok, mi to stačí, ale posílat věci které fungujou úplně jinak než potřebuju? proč?

[vlastik]

tomu co popisuješ se říká pesimistic locking

[pools]

Ne.

[l0gik]

Jo

[pools]

Není to na co jsem se ptal. Absolutně. Chtěl jsem vědět, jestli existuje něco přímo na úrovni SQL serveru. Ne aplikační vrstvu.

[Josef Kufner]

Občas je lepší zvážit jiný přístup, který tvůj problém obchází místo toho, abys ho řešil.

[l0gik]

Jenže ono žádnýho inteligentního člověka nenapadlo, že to myslíš pouze a jenom přes SQL server, protože přes něj to přes víc spojení prostě ani principiálně nejde a nemůže jít (teda pokud si nebudeš držet furt otevřený spojení do db, což jaksi na webu nejde). Což bys jaksi zjistil, kdyby sis o tom něco přečet, jak kolega doporučoval. Stejně jako by ses dozvěděl, že to, jestli jde o pesimistic nebo optimistic locking vůbec neznamená, že se zamyká v aplikační vrstvě....

[pools]

"Nevíte někdo jestli neexistuje něco jako nastavení času platnosti zámku v Postgresu? " << chtěl jsem vědět pouze tohle. Pessimistic lock momentálně používám a jediné co jsem chtěl vědět, bylo jestli existuje v postgresu něco podobného. Napadlo mě to pouze pro zajímavost, protože vím, jak se dá zamknout řádek pomocí klíče. Možná jsem málo zdůraznil, že mě zajímá jen tato informace a ne obecné řešení.

[l0gik]

Jenže právě ta otázka byla natolik nesmyslná, že je evidentní, že Ti schází potřebný background. A že běz něj v lepším případě vymyslíš kolo, v horším něco zbastlíš.

Je to, jako by ses zeptal, jak se ve škodovce naklápěj listy vrtule a čílil by ses z odpověděli, že si máš přečíst něco o rozdílu mezi autem a letadlem.

[pools]

...

[FooBar]

Naprosto jednoznacne jo. Optmistic/pesimistic concurrency control je zakladni princip rizeni soubeznyho pristupu k datum, nikoliv konkretni implementace.

Poslal jsem ti odkaz na neco, co funguje jinak nez si myslis ze potrebujes, ponevadz je to reseni naprosto funkcni a korektni. Priste te proste jen poslu do hajzlu.

[l0gik]

Zaprvý, zcela jasně jsi se nezeptal, z dotazu nijak neplyne, jestli jsi schopen držet transakci během doby, kdy to chceš mít zamknutý, navíc mluvíš o zamykání tabulky a ne záznamu. A zadruhý, radit se mi člověku, kterej se chová takhle arogantně, s prominutím nechce.

Protože teprv teď vyplynulo, že to má bejt asi webová apliakce a transakci držet nemůžeš, tak by mě zajímalo, jak bys řešil to, že když to hypoteticky zamkneš postgresím zámkem na 15min, tak že request na změnu a odemčení poběží ve svý samostatný transakci a tedy se taky přes zámek nedostane...

[pavlix]

Je to casto pouzivany reseni napr. na wiki, na zaklade predpokladu ze realne to tak moc lidi soubezne editovat nebude. Navic, vzhledem k tomu, ze je to human-readable, muzes pomerne trivialne nabidnout merge vuci novy revizi.

Ovšem nesmíš na takovou wiki uspořádat školení :D. Tam ti totiž několik lidí bude editovat právě tu stránku, kterou ukážeš na plátně.

[trekker.dk]

Jen pro úplnost - SELECT ... FOR UPDATE zamkne záznamy jenom pro čtení jiným SELECT FOR UDPATE. Normální SELECT projde.

[l0gik]

Jo, nevyjádřil jsem se jasně. Zámek pro zápis zakazuje jakejkoli zápis či zamknutí. Zámek pro čtení zakazuje jakejkoli zápis a zámek pro zápis, povoluje zápis pro čtení.

tzn. zamknutí pro čtení: zajistim, že mi to nikdo nezmění pod rukama, ale nebudu to měnit, takže povolím ostatním čtení, i s to pro to čtení také zamknout. tzn. zamknutí pro zápis: budu měnit, takže mimo předešlého zakážu i zámek pro čtení (tzn. člověk, kterej to chce konzistentně si musí počkat, až dokončím změnu).

[vlastik]

Doporučuji si na Google nastudovat pojmy "optimistic locking" a "pesimistic locking" a vybrat si jeden z nich a nevymýšlet jakové kočkopsy :)

[Ivan]

+1 presne tak. Ti kockopsi muzou snadno selhat pri vhodne kombinaci izolacniho levelu a nacasovani. Nejjednodussi je predpokladat, ze nic jineho nez pesimisticke a optimistice zamykani ani neexistuje.

Pokud to neumoznuje vas framework tak je mozna chyba v tom frameworku.

[l0gik]

No já už z něho pochpil,. že v podsttě chce pesimistic locking, až na to, že chtěl, aby mu to zařídila databáze přes několik spojení do ní (což prostě z principu nemůže jít).

Navíc pesimistic locking pro webovou aplikaci je dosti nevhodné, neboť není zajištěné správné odemknutí (tam se to musí obejít nějakym vypršením zámku), navíc to má různý sideefekty jako víc otevřenejch oken browseru, nedostupnost záznamu při restartu browseru a podobný opičárny.