generator neprerusovane rady cisel

[Karel Zak]

On Mon, Feb 11, 2002 at 02:48:04PM +0100, David Zabensky wrote:

 (Chlape, delka radky v mailu ma cca 70 znaku...)

> no jde o to, ze pokud budu mit vice soubeznych procesu jenz pojedou pod 
> transakcema a udelam si neco takoveho jako select next_id from tbl a 
> pote update next_id = next_id + 1. (ci naopak), tak:
> 
> a) pokud budu mit vice procesu zaroven, vsechny dostanou zrejme stejnou 
> hodnotu next_id platnou pro zacatek transakce. tu budou nasledne zvysovat 
> o 1 a dostanu (napr. 3x) stejne ID. Coz je spatne.

 Pokud to odkud se cte next_id zamknete tak se tam dostane prave jen
 jedne proces. Nemluve o tom, ze po update uz tu radku i bez zamku
 nikdo nezmodifikuje az do konce transakce, ktera ten update provedla.
 
 Takze by to mohlo jit i bez zamku, stacila by transakce jen by se
 ta hodnota asi musela zjistovat az po tom update a update by nesmelo
 obsahovat where a nebo pouzivat select for update (viz dale).

 BEGIN;
 UPDATE .. SET id=id+1;
 SELECT id ...;
 nejake pouziti id;
 COMMIT;

> b) pokud tohle budu opakovat v nejakem PLSQL cyklu (v ramci 1 transakce) 
> o neznamem poctu opakovani, (for ...) bude v tom teprve zmatek. mozna to 
> chapu spatne, ale u tohoto reseni ma kazdy backend svoji vlastni privatni 
> kopii dat nad tabulkou se sekvenci, ne? a veskere zmeny jsou ostatnim 

 Sequence jak jsme se minule shodli neni v transakcni.

> neviditelne dokud neprovedu commit. tj. ostatni nevidi jake mam aktualni 
> pouzivane ID.

 Pokud se jedna o normalni tabulku tak je ta zmena neviditelna, ale
 zaroven plati, ze nikdo jiny (=jina transakce) neprovede update na 
 radku, ktera je jiz zmenena a neni commitnuta.

 Take zalezi jak se ptate. Muzete pouzit SELECT FOR UPDATE (viz.
 manual) ktery u radek, ktere nejaka jina transakce modifikovala ceka 
 na jejich commit.

 BEGIN;
 SELECT id FROM ... FOR UPDATE;
 ...pouziti id;
 UPDATE .. SET id=id+1
 COMMIT;
 
> c) jak zjistim, ze nejake vygenerovane ID (tj. jenz bylo precteno) bylo 
> opravdu pouzito (tj. klient pozdeji nevolal rollback)?? navic ty cisla by 
> nemely byt ID jako takove, mel by se z nich generovat obecny text podle 
> ruznych sablon (to ale s problemem nesouvisi).

 Pokud zjisteni, update next_id a pouziti toho cista budou v jedne
 transakci tak rollback zlikviduje vsechno i ten next_id+1.
    
        Karel


-- 
 Karel Zak  <zakkr na zf.jcu.cz>
 http://home.zf.jcu.cz/~zakkr/
 
 C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz