Viskas aprasyta labai korektiskai. Bet SELECT FOR UPDATE lock'a laikys iki pat tranzakcijos pabaigos (nebent paleisti anksciau), o jei iki commit'o bus atliekami dar kazkokie didesni veiksmai (pvz. FIFO item'o apdorojimas), tai gali nepageidaujamai blokuoti kitus procesus. T.y. nepatyrusiam zmogui padavus toki solution'as daugumoj atveju jis veiks, bet galimos anomalijos. Geriausia zodziu ieskotis internete kokio isbandyto SQL FIFO pattern'o. On 2010.05.28 14:25, 2x50 wrote: > Kaip tik, klausimas labai konkretus... Ar uzklausu vykdymo varilkiukas veikia skirtingai priklausomai nuo to ar duomenys > uzlockinti naudojant rowlocka ar table locka? Exclusive ar update nera jokio skirtumo, nes nei X lockas neleisk uzdeti > kito X ar U locko and to paties iraso, taip pat kaip ir U lockas neleis uzdeti kito X ar U locko ant to paties iraso... > Klausimas paprastas, kurioj DBVS yra kitaip? > Aprasytam scenarijuj punktuose 2 ir 3 nera nei U nei X locko, del to sitoks kodas veiks blogai ne del to, kad baze > nesusitvarko su rowlocku, o del to, kad jis turi loginiu spragu. > > Jei 2 ir 3 punktus pakeisti i SELECT MIN(DateCreated) FROM Jobs WHERE InUseBy IS NULL FOR UPDATE arba i UPDATE kazkas > WHERE row = salyga, aprasytas scenarijus yra is viso neimanomas, nes punktas 3 bus ivykdytas tik po punkto 6, ir tokiu > atveju punktas 3 grazins: > a) ta pati irasa, jei jis nebuvo pakeistas ir vis dar atitinka salygas > b) kita atitinkanti salygas irasa, jei ankstesnis irasas buvo pakeistas ir nebeatitinka salygu > > Kadangi as po ranka turiu tik Oracle, del to pabandziau tik su Oracle (abiem atvejais ar SELECT FOR UPDATE ar UPDATE > veikia vienodai), tai smalsu suzinoti, kokia DBVS veikia kitaip. > > "rl"<ask@me.for> wrote in message news:hto6os$dcv$1@trimpas.omnitel.net... >> Labai abstraktus teiginiai, nelabai matau prasmes gincytis. Neaisku ar snekama apie exclusive lock'us ar apie update >> lockus... >> >> Nebent turi kazka pasakyti apie mano zemiau isvardintus punktus ir kas juose negerai. >> >> On 2010.05.28 13:10, 2x50 wrote: >>> Tai yra kai lockinta lentele ir kai lockintas irasas, uzklausos vykdomos pagal skirtinga logika - iraso atveju >>> ivykdoma >>> uzklausa neatsizvelgiant i tai, kad irasas nepasiekiamas, o lenteles lockinimo atveju, laukia kol atsilaisvins irasas >>> ir >>> tik tada ivykdo uzklausa? As teisingai suprantu? Cia kokioj DBVS taip yra? >> >>>>>> UPDATE Jobs >>>>>> SET InUseBy = 'Jonas' >>>>>> WHERE DateCreated = (SELECT MIN(DateCreated) FROM Jobs WHERE InUseBy IS NULL) >>>>>> >>>>>> 1. Paleidi 2 tokius pacius update'us vienu metu >>>>>> 2. 1-as ivykdo (SELECT MIN(DateCreated) FROM Jobs WHERE InUseBy IS NULL). Gauna DateCreated reiksme >>>>>> 3. 2-as ivykdo (SELECT MIN(DateCreated) FROM Jobs WHERE InUseBy IS NULL) gauna ta pacia DateCreated reiksme >>>>>> 4. 1-as uzsilockina update'inimui konkretu irasa >>>>>> 5. 2-as bando lockinti ta pati irasa ir laukia >>>>>> 6. 1-as pakeicia InUseBy = 'Jonas' ir paleidzia lock'a >>>>>> 7. 2-as uzsilockina irasa, pakeicia InUseBy = 'Petras' ir paleidzia. >>>>>> >>>>>> Galima situacija? >>>>> >>>>> >>> >>> > >