Kiedy używać transakcji?

Odpowiedz Nowy wątek
2018-11-08 10:19
Krwawy Ogórek
0

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..

Se wzywaj. :P Ja bardzo rzadko uzywam transakcji. Prawie wcale w aplikacji a pod bazą, tylko jak robię dużego DELETE. - Marcin.Miga 2018-11-08 11:08
No to też jest jakaś odpowiedź - transakcje są praktycznie niepotrzebne i się ich nie stosuje :P - cerrato 2018-11-08 11:18

Pozostało 580 znaków

2018-11-08 10:31
1

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.

a co to jest uzasadniona potrzeba? Dla mnie osobiście dużo lepsze rozwiązanie to info przy próbie edycji dokumentu, że ktoś go już edytuje zamiast info przy próbie zapisu (po np. 20 minutach zmian), że nie mogę go zapisać bo go ktoś zmienił w międzyczasie. - abrakadaber 2018-11-08 10:34
Jeżeli edytujesz duży obiekt, którego edycja rzeczywiście zajmuje kilka minut to w pełni się zgadzam. Jednak jeżeli masz do edycji zaledwie kilka pół, w dodatku na obiekcie, do którego współbieżny dostęp występuje bardzo rzadko to trochę wyjeżdżanie z czołgiem na muchę, optymistyczna współbieżność w zupełności tu wystarcza. Zwłaszcza, że ktoś może np. podnieść sobie do edycji obiekt i iśc na kawę, a blokada wisi kilkanaście minut i blokuje prace innym, którzy chcieliby edytować obiekt. - Progress 2018-11-08 10:39

Pozostało 580 znaków

2018-11-08 10:32
1
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ą.


Chcesz pomocy - pokaż kod - abrakadabra źle działa z techniką.

Pozostało 580 znaków

2018-11-08 10:41
5

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.

Pozostało 580 znaków

2018-11-08 10:42
2
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.

Pozostało 580 znaków

2018-11-08 11:15
Krwawy Ogórek
0

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ę.

Pozostało 580 znaków

2018-11-08 11:23
0

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...)

ostatnio była o tym dyskusja dodać należy, że obie strony były równie zawzięte ;) - grzesiek51114 2018-11-08 11:38

Pozostało 580 znaków

2018-11-08 11:26
3
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.


#Dżunior React Devloper wanna be#

Pozostało 580 znaków

2018-11-08 11:40
2

...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.

edytowany 1x, ostatnio: grzesiek51114, 2018-11-08 11:41
znam ten ból, nietypowane datesety, kilkaset tabel w bazie, ależ była zabawa :D - neves 2018-11-08 11:53
ech... @neves mogę o tym książkę napisać. ;) - grzesiek51114 2018-11-08 11:56

Pozostało 580 znaków

2018-11-08 13:23
1
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.


"HUMAN BEINGS MAKE LIFE SO INTERESTING. DO YOU KNOW, THAT IN A UNIVERSE SO FULL OF WONDERS, THEY HAVE MANAGED TO INVENT BOREDOM."

Pozostało 580 znaków

2018-11-09 11:32
0

Co do ORMa to poczytaj o nHibernate.

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0