Mono "geras" kodas:

                       $dbh->begin_work   or die $dbh->errstr;
                    my ($id) = $dbh->selectrow_array(qq{SELECT id FROM 
queue1 WHERE owner IS NULL ORDER BY id ASC LIMIT 1 FOR UPDATE});
                        $dbh->do(qq{UPDATE queue1 SET owner='tezt1' WHERE 
id=$id});
                        $dbh->commit     or die $dbh->errstr;


"2x50" <a@a.a> wrote in message news:htdcgu$6v6$1@trimpas.omnitel.net...
> Sveiki atvyke i transakciju pasauli...
> Blokuoto iraso kita transakcija negales skaityti lygiai tiek laiko, kiek 
> tas irasas yra blokuotas. Kita transakcija nepuola skaityti kito 
> atitinkancio salygas iraso, o laukia kol atsilaisvins reikalingas irasas. 
> Taigi,
>
> select row_1 for update
> commit
> select row_1 for update
>
> abu select sakiniai grazins ta pati irasa. Del to butina bus pakeisti 
> irasa taip, kad antrasis select sakinys grazintu kita irasa.
>
> Aprasytu atveju, greiciau reiktu daryti sitaip (jei gaunasi)
>
> begin transaction
> update row set in_use = user_name
> where row_id = (select row_id where row = oldest_row)
> do work
> commit
>
> zinoma, tai pseudo kodas... :)
>
> Be to reikia parinkti teisinga transaction isolation level (manau, uztektu 
> read uncommited) siom konkreciom transakcijom (nebutinai globaliai visoms 
> transakcijoms)
> http://www.databasejournal.com/features/mysql/article.php/3393161/MySQL-Transactions-Part-II---Transaction-Isolation-Levels.htm
>
> Jei daryti select  for update, tai gausis, kad visos konkuruojancios 
> transakcijos bus sustatytos i viena eile, nes visos nores selectinti ta 
> pati irasa (pati seniausia). Tokiu atveju viena transakcija stabdys visas 
> kitas, kol ji nebus uzbaigta. Todel siulau siuo atveju daryt is karto 
> update vietoj select for update ir naudoti read uncommited isolation 
> level'i. Nes cia vienas is retesniu atveju, kai dirty read'ai bus naudingi 
> ir kelios transakcijos gales vienu metu dirbti su keliais irasais. Tai 
> negarantuoja FIFO principo 100%, bet principas bus labai artimas FIFO. Dar 
> vienas svarbus momentas yra tas, kad do work dalis is pseudo pavyzdzio 
> PRIVALO BUTI TOS PACIOS TRANSAKCIJOS DALIMI. Taigi, jei do work dalis yra 
> daroma ne bazeje, o, tarkim, kliento aplikacijoj, reikes sugalvoti 
> gudresni mechanizma...
>
> Beje, dar toks mazas momentas
>
> UPDATE Jobs
>   SET InUseBy = 'Jonas'
> WHERE DateCreated = (SELECT MIN(DateCreated) FROM Jobs WHERE InUseBy IS
> NULL)
>
> gali pakoreguoti daugiau nei viena irasa, taigi cia turetu buti siek tiek 
> gudresne uzklausa...
>
> "Liofka" <liofkanews@safe-mail.net> wrote in message 
> news:ht5ssn$eo9$1@trimpas.omnitel.net...
>> Šiuo atveju net ne pakeisti, o tik nuskaityti. Juk užlokinto įrašo kiti 
>> negalės selektinti ir tuo pačiu nieko apie jį nežinos ir updeitinti 
>> nebandys.
>> Ar vistik yra dar kažkoks "grėblys"?
>
>