Commit a data bezpecne na disku?

[Petr Novotny]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 25 Mar 00, at 14:23, Jan Serak wrote:

> > Dobre. Pokud provedeme predpoklad, ze fflush() (nebo fsync()) dela
> > to, co ma, je mozne predpokladat,
> 
> ... a vime-li, ze dany DBMS to pouziva...

To je mozna jadro veci. Nedava nejaka SQL norma nejake zaruky?

> > ze v okamziku, kdy se COMMIT
> > uspesne vrati, je update/insert bezpecne proveden? Aspon v tom
> > smyslu, ze na disku bezpecne jsou napsana vsechna data
> > potrebna pro provedeni transakce? 
> 
> Ted si nejsem jist, jestli rozumim tomu ''potrebna pro provedeni
> transakce''. Commit transakci uzavira a dopadne-li dobre, je transakce
> ukoncena a nic dalsiho se s ni delat neda. Plati-li oba predpoklady,
> tak commit fyzicky zapise zmenu dat na disk.

Samotne provedeni zapisu na UPDATE... muze trvat nekolik hodin. 
Zapis typu "uzivatel xxx provadi UPDATE... a ja jsem mu potvrdil, 
ze mam vsechna data" je zlomek sekundy. Pokud je na disku 
bezpecne zapsana takovato vec, lze pri obnovovani databaze po 
padu ten UPDATE... provest.

Porad jde o to: Mam data, ktera se _nesmeji_ ztratit. Pres SQL je 
odevzdam databazi. Ve kterem okamziku presne se o ta data 
nemusim starat? Kdyz se vrati COMMIT? Kdyz databaze prestane 
chrochtat? Nikdy?

Jeste jinak: Kdy konci zodopovednost klienta a zacina 
zodpovednost databaze? A je to standardizovano (aspon ve smyslu 
"pokud to je implementovano, tak to musi byt takto"), nebo si to 
kazdy dela, jak chce?

-----BEGIN PGP SIGNATURE-----
Version: PGP 6.0.2 -- QDPGP 2.60 
Comment: http://community.wow.net/grt/qdpgp.html

iQA/AwUBON8BNVMwP8g7qbw/EQIcZgCg0aXCldiYXvKsfukSKkV6ewMb+BsAnjB8
6pBknOC1+ILq+6Vl4EiJ6xo6
=r0yq
-----END PGP SIGNATURE-----
--
Petr Novotny, ANTEK CS
Petr.Novotny na antek.cz
http://www.antek.cz
PGP key ID: 0x3BA9BC3F
-- Don't you know there ain't no devil there's just God when he's drunk.
                                                             [Tom Waits]