Administrace komentářů

Spadlý proces bude těžko pracovat, ale kterýkoli další proces, který bude nějak pracovat s daty bude muset tento chybný soubor řešit.

Přinejhorším najdu soubor, který se teprv kopíruje... Takže další složitost, kvůli tomu, že nemáš atomické přesuny, tak všichni, kdo pracují s daty musí řešit zdali čtený soubor je nebo kus. Fakt skvělý. Zatímco to, že DB aplikace tento soubor prostě ignoruje (což je chování identické tomu, kdyby byla spuštěna o půl ms dřív) je strašlivá chyba. Ano, v zadání to řečeno nebylo - ono se to jaksi předpokládá automaticky. To jako chceš popřít, že konzistence dat a možnost konkurenčního přístupu není žádáná vlastnost? Ufff...

Izolace transakcí je různá, ale atomicita zápisu (tzn. nedělitelnost zapsaných změn) platí nikoli od úrovně serializible, ale už od read commited. Rozdíl v dalších úrovních je akorát v opakovatelnosti čtení, transakce však vždy vidí pouze výsledek ostatních transakcí.

Standarní úroveň izolace transakcí je přinejmenším read commited (osobně za ní považuji repeatable reads) a stadardně je izolace na tyto úrovně nastavena. Read uncommited se používá ve velmi speciálních případech - defakto je to explicitní vyžádání, aby DB porušila atomicitu zápisu. Takže to není třeba řešit, je to vyřešeno, jen má člověk možnost to obejít, když se mu to hodí. Tvůj argument je tedy, jako bys říkal: když jedu autem, musím řešit startování klikou. No podívej: vyndám startér a ono to nestartuje a musím mít kliku.

Navíc to vše se týká zápisu více hodnot atomicky, což ve FS už nejde udělat vůbec, takže se zde pohybujem na úrovni, kteoru FS poskytnout nemůže vůbec. Ten horkotěžko zajistí atomicitu některých operací, což je věc, kterou DB zajistí vždy a za každé okolnosti.