2x50 rašė: > Keletas teiginiu: > > 1. Serializable visada bus letesnis nei kiti isolation leveliai del > vienos paprastos priezasties - DBVS turi atlikti papildomus veiksmus Nevisai :-) Jei lyginsi su pačiu žemiausiu (READ UNCOMMITED) isolation lygiu, tai turbūt taip. Tačiau atgal jau ir aš galiu pateikti teiginį: žemiausias isolation lygis toli gražu *retai* kada tinka elementarioms/dažniausioms užduotims, kurios reikalauja elementaraus consistency; būtent todėl ir numatytasis izoliacijos lygis jau būna gerokai aukštesnis. Šia prasme tavo teiginys jau iš esmės susvyruoja (MySQL'o atveju nėra jokio reišmingesnio skirtumo tarp default ir SERIALIZABLE). > 2. Zodziai serializable ir performance yra antonimai, ypac high > concurency aplinkoje. Nevisai. Serializable izoliacija tik užtikrina, kad lygiagrečios ir _besipešančios_ transakcijos nepridarys inconsistency problemų, tačiau visiškai nebūtinai serializable izoliacija kiek reikšmingiau įtakoja spartą, jei tos transakcijos nesipeša. 3. Zodziai deadlock ir performance yra antonimai, cia net nematau > reikalo kazka bandyti spresti deadlocku pagalba, tai savizudybe. NE. Tai klasikinė transakcinė problema. http://dev.mysql.com/doc/refman/5.5/en/innodb-deadlocks.html > 4. Serializable apsaugo nuo phantomu. Phantomai is principo neimanomi > dirbant su vienu irasu. Phantomas gali atsirasti tik tada, kai tas pats > selectas kartojamas vienoj transakcijoj bent 2 kartus, + to selecto > atrankos kriterijai leidzia jam grazinti daugiau nei viena irasa (select > * from tbl where pk_value = :constant, negali grazinti daugiau nei vieno > iraso). Neginčiju. O pats kokią prasmę įžvelgi tokios FIFO eilės valgyme?: SELECT * FROM `table` ORDER BY ID ASC LIMIT 1 DELETE FROM `table` WHERE `ID` = x Matyt irgi jokios... (tai tik visos programos/apdorojimo FRAGMENTAS, tik esmės iliustravimui; koks dar vyksta apdorojimas ir galbūt daromi kokie select'ai yra neaišku/nežinoma) > Kadangi phantomas cia niekaip negali atsirasti, vadinasi, norint > pagerint greitaveika(!), nera reikalo naudoti serial transakciju. STOP. Greitaveika didinama keičiant variklį, t.y. pereinant nuo MyISAM (ir banalaus visos lentelės rakinimo) į InnoDB (transakcinę), kuri yra gerokai tobulesnė. Ir greitaveika beveik neabejotinai padidėtų vien tik dėl tokio banalaus pakeitimo. O kartu buvo pasiūlyti būdai konkurentiškumui įvesti (įrašų trynimas), naudojant, beje, default isolation level, kas apskritai neįmanoma MyISAM atveju. SERIALIZABLE yra reikalas/prasmė naudoti ne greitaveikai didinti, bet įvardintai FIFO užduočiai spręsti, kai nėra aišku, koks apdorojimas iš tikrųjų vyksta. > shared(!) next-key locks", kas leidzia ta pati padaryti kitai serial > transakcijai, nes S ir S pora yra compatible (zinoma as darau prielaida, > kad konkreciam vapyzdy id yra pirminis raktas) t.y. 2 transakcijos Neleidžia. Jei skaitei atidžiai, tai: „SELECT ... FROM ... _FOR_ _UPDATE_ blocks other sessions from doing SELECT ... FROM ... LOCK IN SHARE MODE or from reading in certain transaction isolation levels“ Neleidžia, nes ORDER BY ir next-key lock'as nesuderinami > > begin transaction > select * from tbl where id = 5 > delete from tbl where id = 5 > end transaction > > tarpusavyje nekonfliktuoja tol, kol nei viena is ju nepasieke delete > sakinio. Konfliktas atsiranti tik tada, kai bent viena transakcija > sukurs X locka. Taigi, potencialiai visos transakcijos po pirmos, kurios Žr. aukščiau. Kitos transakcijos sustoja į eilutę, po pirmosios SELECT'o (FOR UPDATE). Ir tai yra reikalinga FIFO uždaviniui spręsti. > Man tai labiau panasu yra lavono reanimavima, negu sprendima t.y. takrim > ISAM pradeda stabdyti nuo 30 konkurentiniu vartotoju, na gerai InnoDB > prades stabdyti nuo 100. Esme tame, kad pasiekus ta 100 visvien bus > sakes. Tada lieka tik pasiulymas - nusipirkit greitesni proca. Man Kaip manai, ką MyISAM daro, kai daro UPDATE/INSERT/DELETE...? Aha... (InnoDB geba tai daryti konkurentiškai, nerakindamos visos lentelės, o būdai konkurentiškumui buvo pasiūlyti...) > t.y. READ COMMITED atveju oracle tiesiog abortina 2 ir 3 transakcijas Ne abort'ina, o „įvykdo tuščiai“ (jokios klaidos neįvyksta, kai darai DELETE FROM ... WHERE x) , kaip pats anksčiau demonstravai. Tas pats ir MySQL atveju. Taigi, jau daugmaž išsiaiškinom, kad READ COMMITED, FIFO netinka ;-) > SERIALIZABLE atvejis > > <...> > ERROR at line 1: > ORA-08177: can't serialize access for this transaction > ORA-06512: at line 7 > > jokiu deadlocku, serialines transakcijos tiesiog taip neveikia (bent jau > Oracle atveju). Jei MySQL grazins taip pat exception, bus katastrofa, Tai ir yra deadlock'as. Ir tokia situacija yra klasikinė transakcinėje veiksenoje. Ir viskas veikia: laimėjusi sėkmingai įvykdoma, o likusios, kurios besipešdamos sušoko į eilę — NE; gavęs tokią klaidą gali (neįvykusias) transkacijas inicijuoti iš naujo. > Tam, kad pasiketi FIFO principa, reikia ne isolation level keisti, o > selectui deti FOR UPDATE (ka turi ir MySQL), tam, kad sis selectas > sukurtu X locka, vietoj S locko Na, pagaliau išsiaiškinai. ;-) Jei atidžiau skaitytum, tai pastebėtum, ko klausė post'o autorius pateikdamas/lygindamas savo FIFO realizaciją InnoDB (ji jau su FOR UPDATE) ir MyISAM. Taip pat netruktų išsiaiškinti, kad siūlytas būdas UPDATE ... WHERE LIMIT 1 užsideda x lock'ą ir visos transakcijos sustoja sustoja į eilutę besidalindamos id. FIFO :-) > Va dabar viskas buvo ivykdyta is eiles, kadangi kiekviena sekanti > transakcija prasidejo tik po to, kai baigesi ankstesnioji. Visos 3 ivyko > leciau nei pirmi 2 atvejai, nes buvo vykdomos grieztai is eiles. > Tiesiog siuo konkreciu atveju su tokiu select for update, nera jokio > skirtumo ar rakinti viena irasa ar visa lenta, greitaveika bus ta pati... Jei skaitytum atidžiau, tai pastebėtum, kad siūlyti būdai, kaip transakcijos dalinasi/rezervuojasi id (tas pats FOR UPDATE), po ko vyksta konkurentiškas/lygiagretus tolimesnis apdorojimas (nebekalbant apie tai, kad MyISAM atveju, kai kiekvienas modifikuojantis DMLS'as užrakina visą lentą, tai iš principo neįmanoma). Todėl greitaveika bus gerokai didesnė, nes aibės transakcijų, pasidalinusios id prie durų, toliau tęs darbą (tikėtina imlesnį resursams) lygiagrečiai.