Visi lockai visada yra laikomi iki transakcijos pabaigos, kitaip DBVS neatitiks ACID principu. Nesu girdejes tokios DBVS, kuri is karto po UPDATE sakinio ir dar nepasibaigus transakcijai nuimtu locka (juk yra ne tik commit, bet ir rollback komandos). Taip pat nesu girdejes kazkokiu triuku kaip "paleisti anksciau" locka nei baigesi transakcija. Tam DBVS ir turi sudetingus transakciju valdymo mechanizmus, kad to negalima butu padaryti. Cia nebent i vidurius lysti, bet galeciau tik palinketi sekmes norintiems tai daryti production sistemose, o ne pazinimo tikslais... "rl" <ask@me.for> wrote in message news:htoa78$j54$1@trimpas.omnitel.net... > 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? >>>>>> >>>>>> >>>> >>>> >> >>