Kiedy używać transakcji?

Witam,
napisałem kiedyś dwie spore aplikacje desktopowe w C# w połączeniu z SQL Server. Teraz chcę spróbować w ASP.NET CORE C#.
Do dzisiaj nie odpowiedziałem sobie na pytanie: kiedy używać transakcji?
Nie JAK - to wiem. Ale kiedy?

O co chodzi?
Otóż...Jeżeli robię operację SELECT na bazie w celu edycji pojedynczego rekordu, to czy już wtedy uruchamiać transakcję czy dopiero gdy pobieram zestaw rekordów?
Czy zawsze blokować rekordy pobrane z bazy? Np. Poprzez SELECT FOR UPDATE.
Czy transakcją powinien być objęty każdy pobierany rekord, nawet wtedy, kiedy nie zamierzam do modyfikować? Bo gdy wyświetlam jakieś dane, to inna osoba może w tym czasie zmodyfikować rekord, więc informacje w nim nie będą się pokrywały..

Potrafię korzystać z tych mechanizmów, ale brak mi tej kropelki wiedzy i nie potrafię znaleźć odpowiedzi na te pytania.

Nie czuję się pewnie w tym. Wątpliwości..

Używaj wtedy kiedy tego potrzebujesz. Wszystko zależy od konkretnego przypadku biznesowego.

Krwawy Ogórek napisał(a):

Otóż...Jeżeli robię operację SELECT na bazie w celu edycji pojedynczego rekordu, to czy już wtedy uruchamiać transakcję czy dopiero gdy pobieram zestaw rekordów?

Tu nie do końca rozumiem o co chodzi. Po co pobierać zestaw rekordów, skoro chcesz edytować jedne rekord?

Czy zawsze blokować rekordy pobrane z bazy? Np. Poprzez SELECT FOR UPDATE.

Absolutnie nie. Częściej się nie blokuje niż blokuje. Powinieneś wychodzić z założenia, że z defaultu nie blokujesz. Blokadę zakładasz kiedy istanieje uzasadniona potrzeba.

Czy transakcją powinien być objęty każdy pobierany rekord, nawet wtedy, kiedy nie zamierzam do modyfikować? Bo gdy wyświetlam jakieś dane, to inna osoba może w tym czasie zmodyfikować rekord, więc informacje w nim nie będą się pokrywały..

Kiedy wyświetlasz użytkownikowi jakieś informacje to wyświetlasz mu dane takie jakie są w tym konkretnym momencie kiedy chce je wyświetlić. Bardzo rzadko istnieje potrzeba, blokowania edycji w momencie kiedy ktoś robi podgląd obiektu. Jest to specyficzny przypadek, który może wystąpić, ale raczej należy to traktować jako wyjątek, a nie standard.

Krwawy Ogórek napisał(a):

Otóż...Jeżeli robię operację SELECT na bazie w celu edycji pojedynczego rekordu, to czy już wtedy uruchamiać transakcję czy dopiero gdy pobieram zestaw rekordów?

Nawet jeśli tego nie robisz jawnie to i tak operacja ta jest objęta transakcją. Większość baz transakcyjnych nie potrafi zrobić czegokolwiek bez transakcji.

Czy zawsze blokować rekordy pobrane z bazy? Np. Poprzez SELECT FOR UPDATE.

zależy od filozofii jaką przyjmiesz - poczytaj o blokowanie pesymistyczne vs blokowanie optymistyczne. Oba sposoby mają swoje zady i walety a to Ty jako projektant musisz zdecydować, który sposób w danej aplikacji będzie lepszy

Czy transakcją powinien być objęty każdy pobierany rekord, nawet wtedy, kiedy nie zamierzam do modyfikować?

myślę, że to się pokrywa z pierwszym pytaniem

Bo gdy wyświetlam jakieś dane, to inna osoba może w tym czasie zmodyfikować rekord, więc informacje w nim nie będą się pokrywały..

No i? Jeśli będziesz miał 100 userów to możesz być pewny, że część widoków jest "starych". Ale userzy też powinni być tego świadomi

Potrafię korzystać z tych mechanizmów, ale brak mi tej kropelki wiedzy i nie potrafię znaleźć odpowiedzi na te pytania.
Nie czuję się pewnie w tym. Wątpliwości..

Ja nie jestem Ci w stanie powiedzieć kiedy ma być tak a nie inaczej (i zapewne nikt tego Ci nie powie). Na pewno każda zmiana danych w bazie powinna być objęta jawną transakcją.

Przede wszystkim korzystasz już z transakcji. Niejawnie. Robiąc np. INSERT albo UPDATE. Te instrukcje są objęte transakcją.

Co do pobierania danych - nie widzę tu sensu stosowania transakcji. Nic się nie może stać. Transakcje stosujesz głównie w dwóch przypadkach:

1. Wydajność
2. Zabezpieczenie integralności danych.

Jeśli chodzi o wydajność, to wyobraź sobie, że masz do zrobienia 100 INSERTÓW. To jest 100 INSERTÓW do jednej tabelki. Jak już wiesz jeden INSERT to jedna transakcja. Rozpoczęcie i zakończenie transakcji trwa jakiś czas. Więc w tym przypadku rozpoczynasz i kończysz 100 transakcji - NIEJAWNIE. Natomiast, jeśli te 100 insertów włożysz w jawną transakcję, to one już nie rozpoczynają swoich niejawnych, a więc trwa to zdecydowanie krócej.

Jeśli chodzi o integralność danych - to transakcje stosujemy tam, gdzie może coś się spieprzyć. Gdzie jeden rekord jest zależny od drugiego.

Standardowym przykładem jest przelew w banku.

Załóżmy taką sytuację: Z konta A przelewamy 100 zł na konto B:

UPDATE account SET amount = amount + 100 WHERE id = B;
UPDATE account SET amount = amount - 100 WHERE id = A;

W tym momencie obydwa updatey są od siebie zależne. Generalnie, jeśli jeden z nich z jakiegoś powodu nie pójdzie, to drugi też nie powinien. No bo, jeśli coś pójdzie nie tak (błąd w oprogramowaniu, utrata zasilania tuż po pierwszym update itd), no to może wyjść na to, że osoba B otrzymała 100 zł, ale osoba A ich wcale nie przekazała. Dlatego też te dwa updatey MUSZĄ iść w transakcji:

BEGIN TRANSACTION
    UPDATE account SET amount = amount + 100 WHERE id = B;
    UPDATE account SET amount = amount - 100 WHERE id = A;
COMMIT TRANSACTION

(pomijam tutaj obsługę błędów)

W tym momencie, jeśli cokolwiek się stanie po pierwszym update, ale przed drugim (np. utrata zasilania), to nic złego się nie stanie. Transakcja NIE ZOSTANIE scommitowana, a więc zostanie w całości wycofana. Wskutek czego pierwszy UPDATE zostanie cofnięty.

Podobnie, jeśli np. w drugim update będzie jakiś błąd programistyczny, to transakcja też nie zostanie scommitowana.

Właśnie w takich przypadkach należy używać transakcji.

abrakadaber napisał(a):

Krwawy Ogórek napisał(a):

Otóż...Jeżeli robię operację SELECT na bazie w celu edycji pojedynczego rekordu, to czy już wtedy uruchamiać transakcję czy dopiero gdy pobieram zestaw rekordów?

Ja nie jestem Ci w stanie powiedzieć kiedy ma być tak a nie inaczej (i zapewne nikt tego Ci nie powie). Na pewno każda zmiana danych w bazie powinna być objęta jawną transakcją.

No nie. Jeśli robisz jeden INSERT albo jeden UPDATE, to zupełnie bez sensu pakować to w jawną transakcję. Te instrukcje i tak odpalają swoje NIEJAWNE transakcje i to w zupełności wystarczy.

Dziękuję wszystkim za odpowiedzi.

Więc jeżeli robię SELECT z zamiarem aktualizacji danych (np. korekta adresu zamieszkania) nie blokować rekordu klauzulą FOR UPDATE tylko później w kodzie C#...no właśnie, w kodzie C# użyć obiektu transaction czy przy pomocy SQL Transaction zrobić?
Bo można w T-SQL zdefiniować transakcję a można w kodzie C# utworzyć obiekt transakcyjny..

Dla INSERT sprawa jasna, dać w transakcję. I znowu, obiekt w C# czy w T-SQL. Ja wiem, że to męczące pytania, ale wydaje mi się, że to ma znaczenie i nie jest obojętne czy tu czy tu.

Jeszcze jedno pytanie na szybko. Kiedy używać entity framework a kiedy datasetów, dataadapterów itp? Czy to zależnie od upodobań programisty, czy np. z ds i da nie korzystać bo już "staroć"? Ktoś kiedyś mi powiedział, że EF jest fajne, gdy pracuje się z małą ilością danych a do dużych zbiorów lepiej używać datasetów.

Pozdrawiam i dziękuję.

INSERT w transakcje? Ale po co? Chyba że wiesz, że dany insert wywołuje jakiegoś wyzwalacz, który robi gdzie indziej UPDATE. Transakcje tylko i wyłącznie do UPDATE. (oczywiście zakładająć, że DELETE nie stosujemy, tylko flagę - ostatnio była o tym dyskusja...)

Juhas napisał(a):

Przede wszystkim korzystasz już z transakcji. Niejawnie. Robiąc np. INSERT albo UPDATE. Te instrukcje są objęte transakcją.

Co do pobierania danych - nie widzę tu sensu stosowania transakcji. Nic się nie może stać.

Wszystkie polecenia DML są objęte niejawną transakcją, SELECT, również. I przy pobieraniu danych też mogą się stać różne złe rzeczy, w zależności od tego jaki mamy poziom izolacji ustawiony: brudne odczyty, niepowtarzalne odczyty, fantomy, plus gratisowo utracone modyfikacje ale to bardziej problem z UPDATE.

Jawnie transakcji używamy wtedy kiedy chcemy wykonać więcej niż jedno polecenie jako jednostkę(atomowo) i w izolacji.

...do dużych zbiorów lepiej używać datasetów.

Pracuję w takim projekcie i chętnie wybatożyłbym tyłek osobie, która podjęła taką decyzję.
Można używać nawet microORM'a ale błagam, nie gołych DataSetów.

Krwawy Ogórek napisał(a):

no właśnie, w kodzie C# użyć obiektu transaction czy przy pomocy SQL Transaction zrobić?

To zależy, czy jesteś programistą C# czy SQL.

Bo można w T-SQL zdefiniować transakcję a można w kodzie C# utworzyć obiekt transakcyjny..

Efekt ten sam.

Jeszcze jedno pytanie na szybko. Kiedy używać entity framework a kiedy datasetów, dataadapterów itp? Czy to zależnie od upodobań programisty, czy np. z ds i da nie korzystać bo już "staroć"? Ktoś kiedyś mi powiedział, że EF jest fajne, gdy pracuje się z małą ilością danych a do dużych zbiorów lepiej używać datasetów.

Jak dla mnie, to EF w ogóle nie jest fajne, nawet jak danych w ogóle nie ma. :P
O ile jest czasem sens użyć DataAdapter czy SqlCommand ze względów wydajnościowych, to używanie DataSetów obecnie nie ma sensu. To nigdy nie było wygodne ani stabilne rozwiązanie.

Co do ORMa to poczytaj o nHibernate.

Tak jak było już tu wcześniej napisane transakcje są przed wszystkim potrzebne gdy wykonuje się grupę operacji aktualizacyjnych (włącznie z dodawaniem i usuwaniem rekordów).
Prosty przykład przekazanie 100zł z rachunku A na B. Jeżeli A-100 i nastąpi błąd będziesz miał problem bo w zapisach księgowych z rachunku A zniknie 100 zł, a ta kwota nie pojawi się na rachunku B. Tak więć tansakcja pozwala zatwierdzić zmiany dopiero wtedy gdy wszystkie operacje w grupie zostaną wykonane prawidłowo.