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