Transakcje w Service Broker

Transakcje w Service Broker gwarantują, że wiadomość zostanie dostarczona dokładnie raz mimo awarii.

Rola transakcji w SQL Server Service Broker

Transakcje w SQL Server Service Broker łączą operacje na danych z operacjami kolejkowania wiadomości. Oznacza to, że odebranie komunikatu z kolejki, zmiana stanu tabeli oraz wysłanie odpowiedzi mogą zostać wykonane w jednym atomowym kontekście transakcyjnym. Jeżeli wszystkie instrukcje zakończą się powodzeniem, transakcja jest zatwierdzana poleceniem COMMIT. Gdy wystąpi błąd, aplikacja może wykonać ROLLBACK, a SQL Server wycofa zmiany wykonane w ramach tej transakcji.

W praktyce mechanizm ten zapobiega sytuacji, w której aplikacja trwale usuwa wiadomość z kolejki, ale nie zapisuje odpowiadającego jej wyniku w bazie. Przy odbiorze komunikatu instrukcją RECEIVE wiadomość jest pobierana w ramach transakcji. Jeśli transakcja zostanie wycofana, komunikat pozostaje dostępny do ponownego przetworzenia. Dzięki temu awaria procesu, błąd połączenia z bazą albo wyjątek w procedurze obsługi nie musi prowadzić do utraty komunikatu.

Przetwarzanie komunikatu i potwierdzenie

Typowy odbiorca Service Broker rozpoczyna transakcję, wykonuje RECEIVE z określonej kolejki, odczytuje zawartość komunikatu i realizuje właściwą operację biznesową. Następnie może wysłać komunikat odpowiedzi przy użyciu SEND ON CONVERSATION. Zatwierdzenie transakcji obejmuje zarówno pobranie wiadomości, jak i zmiany dokonane przez kod obsługujący komunikat. Jeżeli odpowiedź ma zostać wysłana tylko po poprawnym przetworzeniu danych, można wykonać te czynności w tej samej transakcji.

Wysłanie wiadomości przez SEND nie oznacza natychmiastowego przesłania jej do procesu po drugiej stronie. SQL Server zapisuje komunikat w infrastrukturze Service Broker i zapewnia jego dalszą obsługę zgodnie ze stanem konwersacji, trasą oraz dostępnością usługi docelowej. Transakcyjność chroni operację zapisu i zmian w bazie, natomiast dostarczenie zależy również od poprawnej konfiguracji usług, kolejek, kontraktów, tras oraz identyfikatora konwersacji.

Service Broker wykorzystuje konwersacje, czyli logiczne kanały komunikacji między usługami. Wiadomości należące do jednej konwersacji są porządkowane, a mechanizmy potwierdzania i ponawiania obsługują błędy występujące podczas transportu. Nie należy jednak utożsamiać tego z gwarancją, że dowolny kod aplikacji wykona operację biznesową tylko raz. Jeżeli program wycofa transakcję po częściowym wykonaniu zewnętrznego działania, to ponowne przetworzenie komunikatu może powtórzyć działanie poza SQL Server.

Izolacja, blokady i ponowne próby

Transakcja odbierająca komunikat podlega regułom współbieżności SQL Server. Instrukcja RECEIVE pobiera wiadomości z kolejki i może powodować blokowanie zasobów do czasu zatwierdzenia albo wycofania transakcji. Czas przetrzymywania transakcji ma znaczenie dla wydajności: długie przetwarzanie zwiększa czas blokad, opóźnia dostęp innych aktywacji do kolejki i może powodować narastanie liczby oczekujących komunikatów.

Procedura obsługi powinna rozróżniać błędy przejściowe od trwałych. Przy błędzie przejściowym wycofanie transakcji pozwala ponowić odbiór komunikatu po usunięciu przyczyny, na przykład po przywróceniu dostępności wymaganej tabeli lub zasobu. Błąd danych, którego ponowne uruchomienie nie naprawi, może jednak powodować wielokrotne nieudane próby. SQL Server Service Broker ma mechanizm ochrony przed tak zwanymi wiadomościami truciznami: po serii kolejnych wycofań związanych z obsługą kolejki może ją wyłączyć, aby jeden wadliwy komunikat nie blokował całego przetwarzania.

Bezpieczny projekt odbiorcy powinien zapisywać stan przetwarzania w tej samej transakcji co odbiór wiadomości oraz przewidywać idempotencję operacji. Idempotentna obsługa daje ten sam efekt po ponownym wykonaniu, na przykład dzięki unikalnemu identyfikatorowi żądania zapisanym w tabeli kontrolnej. Jest to istotne zwłaszcza wtedy, gdy komunikat uruchamia także wywołanie systemu zewnętrznego, ponieważ transakcja SQL Server nie może cofnąć operacji wykonanej poza kontrolą silnika bazy danych.

Diagnostyka i bezpieczne wykorzystanie

Problemy z transakcjami Service Broker można analizować, sprawdzając stan kolejek, aktywacji i konwersacji oraz obserwując liczbę wiadomości oczekujących na odbiór. Pomocne są widoki katalogowe SQL Server, między innymi sys.service_queues, sys.transmission_queue, sys.conversation_endpoints i sys.dm_broker_activated_tasks. Pozwalają one ustalić, czy wiadomości czekają w kolejce docelowej, pozostają w kolejce transmisji, czy też konwersacja znajduje się w stanie błędu.

Podczas projektowania należy jawnie określić granicę transakcji, sposób obsługi wyjątków i moment wysłania komunikatu odpowiedzi. Kod powinien zamykać transakcję także w scenariuszu błędu, aby nie pozostawiać otwartych transakcji blokujących kolejkę. Warto również rejestrować identyfikator konwersacji, typ wiadomości, czas rozpoczęcia oraz wynik przetwarzania. Takie informacje ułatwiają odróżnienie opóźnienia transportu od błędu procedury aktywacji i pozwalają sprawdzić, czy ponowienie było skutkiem wycofania transakcji.

Transakcje Service Broker zapewniają więc spójność operacji wykonywanych przez SQL Server oraz niezawodną obsługę komunikatów w ramach skonfigurowanych konwersacji. Sformułowanie „dokładnie raz” wymaga precyzji: mechanizmy brokera chronią przed utratą i niekontrolowanym powielaniem wiadomości w określonym modelu dostarczania, lecz poprawność całego procesu zależy także od atomowego kodu odbiorcy, właściwego kończenia konwersacji i idempotentnej logiki aplikacji.