Domas Mituzas rašė:
>
>> Lyginami ne visiškai tie būdai. Aš lyg ir nepriešpastačiau FOR UPDATE
>> Audrys pasiūlytam variantui, kaip ir neteigiau, kad mano pasiūlytas
>> būdas yra kuo nors pranašesnis, nors veikimo principas iš esmės
>> analogiškas: pirma konkuruojančiai išsidalinami id, o toliau jau dirbama
>> lygiagrečiai.
>
> Aš čia nelabai ir suprantu, ko norima - ar greito id išdalinimo, ar
> pilnos veiklos serializacijos (kad serializuojamas ir galas būtų).

Aš suprantu, kad tikrai norima didesnės spartos, nes MyISAM jau stabdo. 
Vienas paspartėjimas beveik garantuotai nusimato, jei bukai pereiti prie 
InnoDB (čia jau į temą SERIALIZABLE ir/ar FOR UPDATE būdai, kas 
simuliuotų MyISAM veikimą). Ar galėtum suabejoti šiuo teiginiu, jį 
sukritikuoti, turint omenyje tą patį hw, InnoDB 1.1 (MySQL 5.5)?

Kitas paspartinimo momentas/etapas, jau perėjus prie InnoDB, būtų 
konkurentiškumo įvedimas (Audrys būdas ar mano siūlytas, nors jis ir 
nėra optimalus), jei tik tai nėra griežtas FIFO.

> deja su RDBMS sunkoka daryt, nes RDBMS locko suteikimo tvarkos
> negarantuoja, o šalutiniais efektais remtis biškį nepatogu.

Tai lock'o suteikimo tvarka ir nesiremiama; remiamasi tuo, kad lock'as 
jau suteiktas ir transakcijos persidengiančiai išsirikiuoja: T1, T2, T3, 
...., Tn ir tam tikru momentu jos vyksta lygiagrečiai/konkurentiškai, 
todėl tikrasis/griežtasis FIFO principas pažeidžiamas jau ir šiuo 
aspektu, jei DBMS negarantuoja tokios pačios jų užbaigimo sekos. Juk 
negarantuoja? (aibė multi-core/multi-thread niuansų ir lygiagretaus 
vyksmo netolygumų).