Czym jest TxF?

TxF to wewnętrzna nazwa nowego komponentu w systemie operacyjnym Windows Vista, związanego z systemem plików. W pełnym brzmieniu nazywany bywa Transactional File System (transakcyjny system plików), a czasem Transactional NTFS (transakcyjny NTFS). Niestety obie te nazwy są mylące, gdyż TxF nie jest nowym systemem plików, a NTFS z natury jest systemem transakcyjnym długo przed wydaniem Windows Vista. Rola TxF sprowadza się w rzeczywistości do zintegrowania transakcji z systemem plików, dzięki czemu twórcy aplikacji mogą w wygodny sposób zostawić troskę o integralność danych podczas operacji dyskowych systemowi operacyjnemu.

Czym jest transakcja

Pojęcie transakcji może się w języku potocznym kojarzyć z transakcją bankową, która również musi spełniać podstawowe cechy transakcji. Dlatego do omówienia tych cech użyjemy przykładu transakcji przelewu bankowego z konta na konto, która wiąże się z wykonaniem dwóch elementarnych operacji - zmniejszenia stanu pierwszego konta i zwiększenia stanu drugiego.

Atomowość

Transakcja stanowi nierozerwalną całość. Przykładowa transakcja nie ma prawa skończyć się z żadnego powodu w środku, gdy pewna suma z jednego konta została już zdjęta, a na drugim się nie znalazła. Ma jedynie prawo zakończyć się sukcesem albo być wycofana.

Spójność

Stan kont musi być spójny zarówno na początku jak i na końcu operacji, transakcja nie może doprowadzić do stanu, w którymś jakieś reguły nie są spełnione, np. gdy w przykładzie nie zgadza się bilans.

Izolacja

Operacje dokonywane wewnątrz transakcji muszą być niezależne od reszty systemu. System powinien "widzieć" tylko sytuację tylko przed i po transakcji. W przykładzie, gdyby razem z przelewem odbywała się inna operacja, niedopuszczalne jest aby była jakakolwiek możliwość sprawdzenia chwilowego stanu kont podczas wykonywania transakcji.

Trwałość

W momencie kiedy transakcja jest skończona, powinno być zagwarantowane przetrwanie takiego stanu, bez względu na przyszłe zdarzenia. Przykładowo gdy klient dostanie potwierdzenie przelewu, dalszy brak prądu nie powinien skutkować anulowaniem tej operacji.

Tak więc operacja przelewu spełnia warunki transakcyjności, kiedy system bankowy widzi tylko dwa stany zewnętrzne - ten przed przelewem i po przelewie, z czego ten drugi może odpowiadać jedynie dwu sytuacjom - pozytywnego zakończenia transakcji lub wycofania transakcji.

Implementacja

Znając podstawowe cechy transakcji, można przejść do kwestii, jak TxF będzie realizował operacje w systemie plików. Właśnie dzięki temu, że TxF działa on na poziomie podstawowych operacji na plikach, istnieje możliwość przechwycenia wszystkich odwołań do funkcji API i wykonania ich w pewien szczególny, zmodyfikowany sposób. Przykładowo, gdy aplikacja tworzy plik wewnątrz transakcji, jest możliwość przejęcia tej operacji i zapamiętania informacji o utworzeniu pliku w taki sposób, by dopiero po pozytywnym zakończeniu transakcji system "widział" plik jako nowo stworzony. Podobnie przy modyfikacji istniejącego pliku TxF ma możliwość zapamiętania początkowego stanu pliku i zapisania go, by na wypadek wycofania transakcji przywrócić plikowi początkową zawartość.

Wycofanie transakcji może być spowodowane sytuacją wyjątkową, taką jak awarią systemu czy awarii aplikacji. W pierwszym przypadku po ponownym starcie systemu zostaną wycofane wszystkie niezakończone transakcje, zaś w przypadku awarii aplikacji i niespodziewanego jej zakończenia system automatycznie wycofa wszystkie transakcje rozpoczęte przez tą aplikację. Oczywiście transakcja może być wycofana nie tylko w sytuacji poważnej awarii, w dowolnym momencie aplikacja sama może zażądać cofnięcia transakcji.

Czas trwania transakcji

Gdy bierzemy pod uwagę pracę aplikacji z dużym dokumentem, w którym dochodzi do wielu zmian, oczywiście niekorzystne byłoby ujęcie wszystkich operacji na pliku w jedną transakcję. Dużo lepszym wyjściem jest rozdzielenie modyfikacji dokumentu na krótsze transakcje i okresowe tworzenie przez aplikację punktów kontrolnych, w których kończona jest dotychczasowa transakcja i rozpoczynana nowa. Transakcje długie, trwające wiele godzin nie są zjawiskiem pożądanym. Istnieje bardzo wiele czynników, które mogą spowodować samoczynne wycofanie transakcji przez system. Przykładem takiej sytuacji jest chociażby skończenie się zasobów systemowych. Wtedy system najprawdopodobniej sam zadecyduje o wycofaniu transakcji.

Kiedy stosować transakcje

Istnienie TxF nie wymusza stosowania go, możliwe jest nadal tradycyjne korzystanie z systemu plików. W szczególności, wszystkie aplikacje napisane przed stworzeniem Windows Vista będą niewątpliwie odwoływały się do systemu plików w tradycyjny sposób. Warto zatem zastanowić się, kiedy korzystanie z mechanizmu transakcji jest wskazane. Z pewnością wliczają się do tej grupy wszystkie operacje modyfikujące zawartość jednego lub wielu plików (niekoniecznie na jednym komputerze), jeśli aplikacji zależy na utrzymanie spójnego stanu na dysku w każdym momencie. Operacje dyskowe nie gwarantują bowiem, co zostanie faktycznie zapisane na nośnik, jak i kiedy.

Prostym przykładem obrazującym niedogodności związane z brakiem transakcyjności jest zapis pliku. Zazwyczaj gry program zapisuje na dysk, tylko pewna część informacji fizycznie znajduje się na dysku. System plików może część informacji zapisać na dysku od razu, ale niekoniecznie. Dopiero operacja flush (zapisania bufora pamięci na dysk) zapewnia dokonanie zapisu. Sytuacja ta jest nieprzewidywalna, a w związku z tym trudna do zapanowania. Z tego względu często aplikacje nie modyfikują zawartości plików "w miejscu", a tworzą kopię pliku pod inną nazwą i tę kopię modyfikują. Następnie zmieniają nazwę oryginalnego pliku, by następnie zmienić nazwę nowego pliku na starą i dopiero gdy ten ciąg operacji się powiedzie, oryginalny plik jest kasowany. To skomplikowane rozwiązanie, w którym w żadnym momencie nie jest aktualizowany właściwy plik z danymi, zapewnia w pewnym zakresie spełnienie założeń transakcyjności. Jednak zawsze może dojść do przerwania takiego ciągu operacji, które doprowadzi do niespójnego stanu. Można przekonać się o tym w prosty sposób na przykładzie pakietu Microsoft Office. Gdy jeden z jego składników zostanie zamknięty z powodu błędu, przy ponownym uruchomieniu proponuje on pracę na oryginalnej wersji pliku lub wersji już zmodyfikowanej, tak aby nie utracić wprowadzonych zmian.

Tak więc w dzisiejszych systemach operacyjnych dość skomplikowana logika musi być wykonywana na poziomie aplikacji.  Ideą TxF jest przeniesienie tych operacji do systemu plików i zdjęcie z aplikacji obowiązku troski o niespójny stan dysku. Gdy funkcje te realizuje TxF, praktycznie nie ma możliwości, żeby dane pozostały niespójne.

Równoległe transakcje

Ze względu na konieczność wykonywania równoległych operacji, został utworzony nowy model blokad, który gwarantuje przewidywalny i spójny model wykonywania dwóch równoczesnych operacji na tym samym pliku. W dotychczasowych systemach Windows istnieje pojęcie współdzielenia pliku. Przy otwieraniu pliku można zadecydować, czy będzie plik będzie współdzielony z innymi aplikacjami odczytującymi go, czy w trybie z możliwością zapisu. W nowym modelu te wszystkie stare sposoby współdzielenia pliku będą respektowane. Doszedł jednak nowy tryb blokowania plików zwany blokowaniem transakcyjnym. Zapewnia on, że istnieje tylko jedna transakcja modyfikująca dany plik.

W przypadku gdy dwie równoległe transakcjach żądają otwarcia pliku w trybie do odczytu i zapisu, druga z operacji skończy się błędem. Jednak gdy wszystko odbywa się w ramach jednej transakcji, dwie operacje modyfikacji tego samego pliku nie muszą spełniać zasad izolacji transakcyjnej, a więc dopuszczalne jest otwarcie pliku przez obie. Ciekawym przypadkiem jest sytuacja, gdy w ramach jednej z transakcji odbywa się modyfikacja pliku, zaś w drugiej transakcji żądane jest otwarcie pliku w trybie tylko do odczytu. Taka operacja zakończy się sukcesem, jednak do drugiej operacji zostanie przekazany izolowany uchwyt do pliku, czyli uchwyt do pliku znajdującego się w stanie początkowym, w celu zachowania izolacji.

Istnieje możliwość otrzymania powiadomienia, kiedy jedna transakcja zostanie zakończona, aby móc wykonać inną operację na pliku, co realizuje się dopisując operację na końcu transakcji i po jej zakończeniu ponownie otwierając plik i otrzymując w wyniku uchwyt do zmodyfikowanego już pliku. Inna sytuacja występuje, gdy plik jest otwierany "tradycyjnie" na odczyt, ale wcześniejsza transakcja trwa. W takiej sytuacji operacja odczytu zwróci "izolowany" uchwyt, gdyż izolacja odbywa się domyślnie podczas wykonywania jakiejkolwiek transakcji. Izolacja jednak trwa tylko dopóki transakcja jest aktywna, tak więc w momencie zakończenia transakcji, uchwyt zwrócony wcześniejszej operacji otwarcia do odczytu będzie wskazywał na plik z nowymi danymi.

Tak więc wszystko jest kompatybilne ze starym modelem za przedstawionego przed chwilą dość szczególnego przypadku. Jednak nie ma tak wiele dzisiejszych aplikacji otwierających plik na odczyt w trybie współdzielenia go z innymi. Raczej otwiera go w trybie, w którym nie można zmodyfikować go równocześnie.

TxF od strony programistycznej

Dostęp do TxF zapewniony jest poprzez interfejsy API na wielu poziomach. Istnieją interfejsy API na poziomie Win32, na poziomie OleTx/DTC/COM+/COM, a nad tym jest oczywiście zestaw API na poziomie WinFX zawarty w przestrzeni nazw System.Transactions. Transakcyjność na poziomie Win32 jest nieco ograniczona zakresem, nie pozwala na transakcje rozproszone. Transakcje rozproszone są możliwe dzięki interfejsom API wyższego poziomu realizującym mechanizm zatwierdzania dwufazowego. Przykładem rozproszonej transakcji z wykorzystaniem TxF może być wykonywanie w ramach jednej transakcji operacji plikowych i bazodanowych.

W transakcjach rozproszonych, do koordynacji elementów biorących w nich udział wykorzystywany jest DTC (Distributed Transaction Coordinator), obecny w wielu obecnych systemach Windows. SQL Server jest klientem przystosowany do wykonywania transakcji rozproszonych poprzez mechanizm dwufazowego zatwierdzania. W systemie Windows Vista mechanizm ten zaimplementowany został w trybie jądra, a rolę koordynatora transakcji spełnia tam Kernel Transaction Manager. Nadzoruje on w jądrze nie tylko TxF, ale również nowy komponent odpowiedzialny za transakcyjny dostęp do rejestru - TxR. Zarówno TxF, TxR, jak i KTM korzystają z innego komponentu obecnego w systemie Windows od czasu Windows Server 2003 R2 - CLFS (Common Log File System). CLFS to szybki system logowania, udostępniający również interfejsy w trybie użytkownika, gotowe do użycia przez aplikacje (Win32 i w kodzie zarządzalnym) w każdym innym celu logowania.

W przypadku transakcji związanej z dostępem z TxF i SQL Server, aplikacja rozpoczyna transakcję poprzez interfejs DTC. Jeśli to aplikacja w kodzie zarządzalnym, odbywa się to poprzez klasy z przestrzeni nazw System.Transactions, w przypadku aplikacji Win32 byłoby to bezpośrednie wywołanie API DTC. W kolejnym kroku aplikacja mogłaby otworzyć wewnątrz transakcji połączenie z SQL Server, który dopisałby się do DTC jako członek transakcji rozproszonej. Następnie aplikacja wywoła kolejne API, które spowoduje wywołanie transakcji na poziomie jądra, a w gruncie rzeczy wobec TxF. Tak samo TxF komunikuje się z KTM angażując się (zgłaszając zainteresowanie) istniejącą transakcją. Transakcja KTM jest częścią transakcji DTC jako transakcja niższego poziomu.

System reaguje na błędy na różnego rodzaju poziomach, np. gdy z jakiegoś powodu komunikacja z SQL Serverem zostanie przerwana, DTC wykryje, że brakuje jednego z członków transakcji. Transakcja zostanie wycofana, poprzez wszystkich obecnych członków. Kiedy komunikacja z SQL Serverem zostanie przywrócona, SQL Server skomunikowałby się z DTC, aby sprawdzić stan transakcji i DTC spowoduje również wycofanie transakcji bazodanowej. Wszystko odbywa się przez znany od dłuższego czasu mechanizm dwufazowego zatwierdzania, który został przeniesiony do jądra systemu i dzięki temu zyskał nowych potencjalnych członków.

Wpływ na bezpieczeństwo

Transakcyjność systemu plików powinna być rozwiązaniem neutralnym pod względem bezpieczeństwa systemu - nie wprowadzającym zmian w pozytywnym i negatywnym aspekcie. Model zabezpieczeń systemu transakcji zapewnia, że można być pewnym jej przebiegu, w szczególności szczelności izolacji, braku możliwości złośliwego wycofania itd. Dostęp do KTM kontrolowany jest poprzez listy uprawnień (ACL), a DTC jest składnikiem systemu operacyjnego mało podatnym na ataki. Zatem rozszerzenie zakresu transakcji nie powinno mieć implikacji w zakresie bezpieczeństwa systemu.

Wpływ na wydajność

Oczywistym jest, że przetwarzanie transakcyjne wiąże się z dodatkowym kosztem wydajnościowym. Największy udział ma w tym danie dwóch kosztownych gwarancji - atomowości i trwałości. Oznaczają one, że z każdą czynioną zmianą trzeba tworzyć migawkę (snapshot), a także zapewnić wiarygodny zapis na dysku. Jednak warto spojrzeć na to z innej strony i porównać ten koszt z alternatywnym obciążeniem, jakie spowodowałoby wprowadzenie do aplikacji podobnej funkcjonalności, np. opisywanego wcześniej "bezpiecznego" sposobu zapisywania pliku, ze zmienianiem nazw, utrzymywanie logu pozwalającego być świadomym wprowadzonych w nim zmian. W tym zestawieniu TxF to dużo szybsze rozwiązanie, chociażby dlatego, że odbywa się na poziomie systemu operacyjnego. W związku z tym TxF ma dużo większe możliwości optymalizacji, większe zrozumienie o tym co się tak naprawdę dzieje (można to porównać do jednego programisty tworzącego rozwiązanie). Dużo też daje związek z NTFS i korzystanie z natywnych atrybutów systemu plików. Istnieje np. możliwość zapanowania nad wszystkimi stanami, w których są pliki - czy na dysku czy w pamięci. Można w pewnych sytuacjach wykorzystać mechanizm uprawnień i wiedzę o tym, że pewne prawa nie zostały jeszcze zapisane na dysk. Wszystkich tych informacji nie posiada żadna aplikacja działająca poza systemem, ale również części systemu operacyjnego mają do nich ograniczony dostęp.