On 12/9/11 12:25 PM, 2x50 wrote:
> Keletas teiginiu:
>
> 1. Serializable visada bus letesnis nei kiti isolation leveliai del
> vienos paprastos priezasties - DBVS turi atlikti papildomus veiksmus
> tam, kad serializuoti transakcijas. O papildomi veiksmai reikalauja
> laiko, galbut labai labai mazai, bet visvien jie jo prideda, ne atima.

Tiesa pasakius prie kai kurių workloadų intuityviai 'lėtesni' leveliai 
yra greitesni - nes nereik snapshotų perdarinėt kas kartą, etc :)

> 2. Zodziai serializable ir performance yra antonimai, ypac high
> concurency aplinkoje.

OK!

> 3. Zodziai deadlock ir performance yra antonimai, cia net nematau
> reikalo kazka bandyti spresti deadlocku pagalba, tai savizudybe.

Greitai atrastas deadlockas kartais geriau už blockinimą. ;-)

> 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).

REPEATABLE READ irgi saugo nuo phantomų :-)

> locko sukurimo, is esmes yra siuksles, nereikalingai apkraunancios
> sistemos darba, nes jos ivykdys delete tik tuo atveju, jei ankstesne
> transakcija buvo abortinta.

Būtent todėl REPEATABLE READ su tiesiogiai išreikštais norais (LOCK IN 
SHARE MODE, LOCK FOR UPDATE) yra teisingesnis priėjimas prie šių problemų).

Enivej, mes eiles konstruojam Audrio aprašytu metodu, skeilina pusę 
velnio (ne tokie gi ir maži esam ;-)

Domas