Pytanie Czy transakcje powinny być określone poza procedurą składowaną lub w środku?


Możemy zawijać wywołanie procedury składowanej w transakcji i określić poziom izolacji.

Lub możemy umieścić transakcję wewnątrz procedury przechowywanej, określając tam poziom izolacji.

Co lepiej zrobić?


14
2018-03-06 12:23


pochodzenie




Odpowiedzi:


Powinieneś przyjąć spójne podejście. Należy pamiętać, że wycofanie transakcji w ramach procedury składowanej spowoduje wycofanie dowolnego zakresu transakcji zagnieżdżania, w tym dowolnego zakresu zewnętrznego.

Radzę zachować transakcje poza procedurami. W ten sposób zachowujesz pełną kontrolę.


7
2018-03-06 12:34



to nie jest poprawne. Jeśli zagnieździsz kilka BEGIN TRANSACTION startów, a najgłębszy z nich wycofa się, wszystkie wycofają ... - MatBailie
@Dems: Częściowo masz rację, jest tak tylko w przypadku, gdy nie używasz transakcji z parametrem nazwa_wyjścia. Dlatego właśnie transakcje powinny być wyraźnie zdefiniowane dla pełnej kontroli. Widzieć msdn.microsoft.com/en-us/library/ms189336.aspx na przykład. - John Sansom
Dems: z jakiegoś powodu napisałem "accept" zamiast "roll back", co nie miało większego sensu. Dzięki za wskazanie tego :-) - Tor Haugen


Wewnątrz procedura przechowywana jest najbardziej odpowiednie miejsce moim zdaniem.

Jedną z podstawowych zasad dobrego projektowania transakcji jest utrzymywanie cyklu życia transakcji w jak najkrótszym czasie, dlatego zatwierdzenie powinno nastąpić natychmiast po zakończeniu logiki transakcji. Kontrolowanie transakcji poza procedurą przechowywaną spowoduje niepotrzebne wydłużenie czasu trwania transakcji.

Należy również wziąć pod uwagę, że zdefiniowanie transakcji w ramach procedury zapewni również większą klarowność kodu. W przeciwnym razie, gdyby inny programista musiał zmodyfikować określoną procedurę przechowywaną, musiałby polegać na fakcie, że wywołujący rzeczywiście zawija procedurę w transakcji. Uwzględnienie transakcji w ramach procedury jednoznacznie określa sposób obsługi transakcji.


5
2018-03-06 12:53



Dla każdego, kto zdecyduje się zdobyć -1, uprzejmie byłoby podać swoje uzasadnienie. - John Sansom


Podobnie jak FYI, Oracle nie obsługuje transakcji zagnieżdżonych, a jeśli rozpoczynasz transakcję na poziomie zewnętrznym, a następnie wywołujesz serię procedur składowanych, każdy przechowywany proces, który wystawia zatwierdzenie, zatwierdza całą transakcję do tej pory, a nie tylko zainicjowana transakcja. Dlatego musisz zarządzać transakcją poza zapisanym procem podczas wywoływania z języków takich jak C #

Pomyślałem, że możesz być zainteresowany, dla porównania.


5
2018-03-06 13:18



Obsługuje on jednak autonomous_transactions, co pozwala zasadniczo rozpocząć nową transakcję poza bieżącą transakcją. Jednak prawie zawsze są złym pomysłem. Obsługuje także zapisywanie punktów. co pozwala na częściowe wycofywanie zmian, chociaż nie jest to coś, z czego skorzystałem. - Matthew Watson


Na zewnątrz lub przynajmniej w zewnętrznej warstwie interfejsu API bazy danych.

Jeśli popełnisz błąd w każdej procedurze przechowywanej, możesz równie dobrze włączyć automatyczne zatwierdzanie, zobrazuj następujące zapisane procedury

create_user_with_email_address
  calls -> create_user
  calls -> create_email_address

jeśli dokonasz zatwierdzenia w obrębie parametru create_user / create_email_address, wówczas parametr create_user_with_email_address nie może już być transakcyjny, jeśli parametr create_email_address nie powiedzie się, użytkownik create_user został już zatwierdzony, a dane są uszkodzone.

Ułóż transakcję tak wysoko, jak to konieczne, aby wszystko w niej pozostało.


4
2018-03-06 13:21



Nie sądzę, aby było to prawdą, jeśli zewnętrzna transakcja zostanie wycofana, również wycofuje wszystkie zagnieżdżone transakcje. - tpower
W zależności od bazy danych niektóre bazy danych nie mają "transakcji zagnieżdżonych", - Matthew Watson
Myślałem tylko o serwerze SQL, ale o dobrym punkcie +1 - tpower


To zależy od logiki biznesowej, jeśli SP jest atomowe, powinno wdrożyć własną transakcję. Jeśli tego nie zrobisz, ryzykujesz błędnym kodem w przyszłości, nie tworząc transakcji owijania. więc w odpowiedzi na twoje pytanie myślę, że transakcja powinna trafić do SP.

Oczywiście nie ma nic, co mogłoby powstrzymać cię od wykonywania obu, atomowe SP wdrażają własne transakcje, a poza tym zasięgiem mogą już istnieć inne, szersze transakcje.

Generalnie podczas tworzenia transakcji wykorzystujących transakcje SP można już znajdować się w zakresie transakcji, należy kodować dla tej instancji podczas wykonywania zatwierdzenia / wycofania.


2
2018-03-06 12:31



Czy transakcja wewnątrz SP nie połączy się z zewnętrznym zasięgiem transakcji, aby zatwierdzanie / wycofywanie działało w sposób transparentny? - Jakob Christensen


Wykonujemy następujące czynności w ramach Sproc, ponieważ po prostu wycofujemy to pomijanie liczby transakcji w zewnętrznych plikach SProc, które mogą wygenerować ostrzeżenie z powrotem do aplikacji - a jeśli nie oczekuje się / obsługi, może spowodować błąd aplikacji .

Jednak ta metoda cofa jedynie transakcję "lokalną", więc zewnętrzni "rozmówcy" muszą odpowiednio interpretować wartość Zwrotu; alternatywnie użyj RAISERROR lub podobnego.

BEGIN TRANSACTION MySprocName_01
SAVE  TRANSACTION MySprocName_02
...
IF @ErrorFlag = 0
BEGIN
    COMMIT TRANSACTION MySprocName_01
END
ELSE
BEGIN
    ROLLBACK TRANSACTION MySprocName_02
    COMMIT TRANSACTION MySprocName_01
END

1
2018-03-06 16:05