Czy transakcje bazodanowe dają 100% gwarancji na poprawność ich działania? Chodzi mi już o tak prymitywne i specyficzne przypadki jak np. odcięcie zasilania elektrycznego komputera podczas wykonywania transakcji.
Pewne są tylko śmierć i podatki. Zawsze może się pojawić jakiś bug ze strony programisty/osoby projektującej. Ale jeśli pominąć czynnik ludzki, to tak, takie jest założenie.
Tak, realizacja tego jest chyba tak prosta jak budowa cepa i wersji mało wydajne zaprogramuje to szympans. Scenariusz wygląda tak:
- W Folderze X tworzysz plik ze strumieniem danych będących migawką stanu obecnego
1.1 Jeśli coś się wysypie, to nie ma problemu, bo jeszcze nie było zmian.
- W Folderze X tworzysz plik .lock
2.1 Jeśli coś się wysypie, to po powrocie widzimy plik .lock i przywracamy migawkę
- Wprowadzasz zmiany
3.1 Jeśli coś się wysypie w trakcie, to po powrocie widzimy plik .lock i przywracamy migawkę
- Zakończyliśmy z sukcesem wprowadzać zmiany
4.1 Mimo wszystko następuje przywrócenie migawki jeśli odetnie nam prąd
- Dopiero, jeśli udało się usunąć plik .lock bez awaryjnie, to znaczy, że całość się powiodła.
5.1 Jeśli nastąpi awaria, to mamy nasz stan integralny i jesteśmy to w stanie stwierdzić na podstawie braku pliku .lock, więc nie ma problemu.
Może jeszcze powstać pytanie, a co jeśli wysypie się podczas przywracania migawki?
Raczej oczywiste, będziemy przywracać, aż się uda, bo do póki się nie uda, nie usuniemy pliku .lock
Przez migawkę mam na myśli zrzut całości systemu, bo to jest w stanie zrobić prymityw, bazy to robią nieco lepiej, ale naprawdę nie wiele. Mechanizm jest podobny.
W takich przypadkach jak opisujesz nie daja I chyba nikt ci nigdy nie da.
Co innego w temacie, co innego w pytaniu…
Tak.
Co masz na myśli? Jeśli coś się stanie w trakcie wykonywania transakcji, to nie zostanie ona zatwierdzona, więc dane w bazie nie ulegną modyfikacji. W zależności od możliwości i konfiguracji SZBD, po powrocie zasilania może nastąpić próba odtworzenia tej transakcji, a jeśli nie to, trzeba będzie ją ponowić od strony klienckiej.
No i transakcje w ogólności nie są zamiennikiem UPSa, więc przykład trochę nietrafiony.
Jak sie wylaczy prad w czasie commitowania tranzakcji (a to tez czasem potrafi chwile zajac) to tez sie moze powalic.
Nie. To znaczy tylko, że baza danych to jakiś no-name. Transakcja, która nie została zatwierdzona, tylko wykonana w części, zostanie cofnięta, przy ponownym uruchomieniu bazy danych.
Tak zgadza sie.
Ale jesli tranzakcja zostanie wykonana to jeszcze musi byc potwierdzona co tez zajmuje jakis ulamek sekundy. Jakbys w tym momencie cos napsul w serwerze to szansa na popsucie istnieje.
Nie. Wykorzystuje się do tego operacje atomowe. Np. Stworzenie pliku .lock. Jeśli plik istnieje, to znaczy, że założono blokadę, jeśli nie istnieje, to znaczy, że blokady nie ma (została zdjęta). Plik nie może istnieć częściowo, to ma tylko dwa stany, albo jest poprawny wpis w jakiejś tam macierzy dysku, albo nie.
Najgorsze co może się stać, to wycofamy, coś co jest poprawne. Tylko o tym nie wiemy, bo jeszcze nie zdążyliśmy ściągnąć blokady (usunąć pliku .lock). Ale o tym nie ma nic w ACID. Czyli wszystko jest poprawnie.Gdyby wysypanie zasilania powodowało nie spójności danych, to życzę powodzenia w istnieniu jakiegokolwiek systemu.