generator neprerusovane rady cisel

[David Zabensky]

Karel Zak wrote:
> On Mon, Feb 11, 2002 at 02:48:04PM +0100, David Zabensky wrote:
> 
>  (Chlape, delka radky v mailu ma cca 70 znaku...)

Diky za upozorneni, snad uz to bude lepsi. Omlouvam se vsem 
ctenarum teto konference.


> 
> 
>>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.

Ano, omlouvam se za nepresne vyjadrovani. Nemyslel jsem 
sekvenci jako objekt DB. Mel jsem na mysli moji pseudosekvenci.

> 
> 
>>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.

Ano, ale jina transakce muze delat nad starou hodnotou 
select (coz v tomto pripade vadi).

> 
>  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
> 
> 
> 


Aha, to by mohlo byt reseni. Koukal jsem na napovedu a zda 
se, ze je to presne to co hledam. Pokud jsem to pochopil 
dobre, tak LOCK TABLE 'my_seq' IN ACCESS EXCLUSIVE MODE 
zabezpeci to, ze zmeny bude moci delat jen ma transakce a 
ostatni budou muset (i se ctenim) cekat na COMMIT/ROLLBACK.

Nepotrebuji to na generovani PK do tabulky. Melo by to 
slouzit pro generovani nazvu kategorii, kde bude textovy
prefix + nejaka ciselna rada.

Moc dekuji, je to zrejme to, co jsem chtel.

David