Transakcja na rekord
AnnaJ
Czy jest mozliwosc zrobienia transakcji ktora nie blokuje calej tabeli, a
jedynie wiersz ktory jest edytowany albo insertowany. Jak rozwiazuje sie
problem kiedy kilku uzytkownikow dziala na tej samej tabeli i blokuja sie
nawzajem.
--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/
wloochacz
> Czy jest mozliwosc zrobienia transakcji ktora nie blokuje calej tabeli, a
> jedynie wiersz ktory jest edytowany albo insertowany. Jak rozwiazuje sie
> problem kiedy kilku uzytkownikow dziala na tej samej tabeli i blokuja sie
> nawzajem.
Jaka baza?
--
wloochacz
adam myszor
Użytkownik "AnnaJ" <lj...@WYTNIJ.gazeta.pl> napisał w wiadomości
news:g1gk6a$os$1...@inews.gazeta.pl...
Z tego co wiem to podczas otwarcia transakcji nie blokuje się dostępu do
tabeli,
inni użytkownicy mogą z tej tabeli korzystać, poprzez select, insert i
update.
Transakcja ma na celu potwierdzenie dodkonanych zmian (commit) lub ich
cofnięcie (rollback) np w przypadku
warunku: wykonane zostaną wszystkie zmiany albo żadna np ze względu na
wystąpienie błędu w programie.
Tranakcja może czasami zajmować dość dużo czasu (wiele zapytań i zmian) w
rozbudowanych bazach więc blokowanie ogólnie dostępu było by tu niewskazane.
Jeżeli zachodzi potrzeba zablokowania danego rekordu ze względu na możliwość
odczytania prze innych użytkowników niejednolotych danych najlepiej te
newralgiczne zmiany zablokować programowo.
Adam
wloochacz
> Z tego co wiem to podczas otwarcia transakcji nie blokuje się dostępu do
> tabeli,
> inni użytkownicy mogą z tej tabeli korzystać, poprzez select, insert i
> update.
> Transakcja ma na celu potwierdzenie dodkonanych zmian (commit) lub ich
> cofnięcie (rollback) np w przypadku
> warunku: wykonane zostaną wszystkie zmiany albo żadna np ze względu na
> wystąpienie błędu w programie.
Tylko że niejako cechą uboczną ACID, jest właśnie blokowanie
(consistency - spójność oraz isolation - izolacja) danych. I robi się
to za pomocą transakcji. Osobną sprawą jest, czy dany SZBD pozwala na
blokowanie na poziomie wiersza, czy tylko strony/tabeli.
> Tranakcja może czasami zajmować dość dużo czasu (wiele zapytań i zmian) w
> rozbudowanych bazach więc blokowanie ogólnie dostępu było by tu niewskazane.
Nie chodzi o blokowanie "ogólnego dostępu" - chodzi o blokowanie
konkretnego wiersza w konkretnej tabeli.
To prawda że blokowanie jest zazwyczaj kosztowną operacją, ale
stosunkowo łatwo można oprogramować z góry określoną ilość blokad. A co
za tym idzie szanować zasoby serwera. Tylko, tak naprawdę, taki problem
zaistnieje przy na prawdę duuużej ilości blokad.
> Jeżeli zachodzi potrzeba zablokowania danego rekordu ze względu na możliwość
> odczytania prze innych użytkowników niejednolotych danych najlepiej te
> newralgiczne zmiany zablokować programowo.
A dlaczego się męczyć, skoro załatwia to za nas baza danych?
--
wloocchacz
adam myszor
Użytkownik "wloochacz" <nospam.w...@nospam.dgbit.pl> napisał w
wiadomości news:g1guhn$a3n$1...@atlantis.news.neostrada.pl...
Dlaczego się męczyć............ już odpowiadam.
Programowo można wykluczyć taką sytuację:
1.Pobranie wartości z rekordu tabeli A
2.Start Transakcja
3.Obliczenia
4.Modyfikacja pobranego rekordu z tabeli A
5.ExecSQL (teraz zależy co się dzieje od ACID - read uncommitted, read
committed, repeatable read, serializable)
6.Modyfikacja rekordu w tabeli B na podstawie danych pobranych wcześniej z
Tabeli A
7.ExecSQL
8.Koniec transakcji (commited lub rollback).
............. i teraz zakładamy po pkt. 5 pobranie przez drugiego
użytkownika wartości rekordu Tabeli A i błąd po pkt 7 powodujący powrót do
stanu pierwotnego rekordu Tabeli A lub brak błędu i zapisane nowej wartości
rekordu w Tabeli A.
I teraz jak to zrobić z poziomu bazy aby ten drugi uzytkownik miał zawsze
aktualną wartość niezależnie czy po pkt 7 użytkownik 1 ma commit czy
rollback???
Ja zawsze rozwiązuję to programowo blokując dostęp do rekordu dopuki
użytkownik 1 nie zakończy tranakcji............. może jest jakieś 100%
rozwiązanie z poziomu bazy danych. ???
wloochacz
> Ja zawsze rozwiązuję to programowo blokując dostęp do rekordu dopuki
> użytkownik 1 nie zakończy tranakcji............. może jest jakieś 100%
> rozwiązanie z poziomu bazy danych. ???
Co to znaczy "rozwiązuję to programowo blokując dostęp do rekordu dopuki
użytkownik 1 nie zakończy tranakcji"?
Ale przecież tak działa blokada - zakładasz ją przed edycją rekordu i
teraz nikt inny nie może zmienić lub nawet przeczytać (zależy od poziomu
izolacji transakcji) zablokowanego rekordu, dopóki blokada nie zostanie
zdjęta - czyli de-facto transakcja nie zostanie zakończona.
Programowa realizacja ma tę słabość, że jest narażona na błędy, czyli
zależy od transakcji w kontekście której tę programową blokadę zakładasz
;-) Czyli może to skutkować tym (widziałem to wielokrotnie) że jakaś
blokada wisi, bo system blokad się zawiesił...
--
wloochacz
adam myszor
OK, OK......... przetestuję to sobie tylko napisz mi proszę jak zakłada się
taką blokadę na rekord w FireBird lub InterBase.
Jak to praktycznie dobrze zrobić.
Adam
Tomek Dzięcioł
>
> OK, OK......... przetestuję to sobie tylko napisz mi proszę jak zakłada się
> taką blokadę na rekord w FireBird lub InterBase.
> Jak to praktycznie dobrze zrobić.
> Adam
Np. tak:
UPDATE tabela SET id = id;
gdzie id to pole będące kluczem głównym tej tabeli.
Od wersji 2.0 (nie jestem pewny) można jeszcze użyć
select x from y with lock
albo coś w ten deseń - doczytaj w dokumentacji.
--
Tomek Dzięcioł
adam myszor
Użytkownik "Tomek Dzięcioł" <br...@adresu.com> napisał w wiadomości
news:g1iult$sn4$2...@news.onet.pl...
A gdzie jest zakladana ta blokada??
Adam
Morff
>> jak zakłada się taką blokadę na rekord w FireBird lub InterBase.
>
> Np. tak:
> UPDATE tabela SET id = id;
hehehe :)
--
Pozdrawiam
Morff
--------------------
AQQ : 141151 (mo...@aqq.eu)
Tomek Dzięcioł
>> Np. tak:
>> UPDATE tabela SET id = id;
Poprawka
UPDATE tabela SET id = id WHERE id = :id;
>>
>> gdzie id to pole będące kluczem głównym tej tabeli.
>>
>> Od wersji 2.0 (nie jestem pewny) można jeszcze użyć
>> select x from y with lock
>> albo coś w ten deseń - doczytaj w dokumentacji.
>
> A gdzie jest zakladana ta blokada??
Wykonanie update na rekordzie blokuje rekord do edycji przez innych
użytkowników. Reszta uzależniona jest od poziomu izolacji transakcji.
--
Tomek Dzięcioł
wloochacz
blokada nie nic wspólnego z użytkownikiem, a z transakcją. ;-)
A że każdy user pracuje (bo musi) na bazie w kontekście różnych
transakcji, to tak ludziska to opisują. No, ale to wg mnie skrót myślowy
- bo taka blokada zadziała i dla tego samego usera, wystarczy odpalić
kilka transakcji/sesji :)
--
wloochacz
wloochacz
>> Np. tak:
>> UPDATE tabela SET id = id;
>
> hehehe :)
--
wloochacz
Morff
napisał:
> [ciach]
>>> Np. tak:
>>> UPDATE tabela SET id = id;
>> hehehe :)
> Co się cieszy - to jest tzw. pusty update :)
>
na rekordzie ?
wloochacz
> na rekordzie ?
No. Na całej tabeli :D
Sorka, zaślepłem; tak lepiej?
UPDATE tabela SET id = :id where id = :id;
--
wloochacz
Tomek Dzięcioł
>> Wykonanie update na rekordzie blokuje rekord do edycji przez innych
>> użytkowników. Reszta uzależniona jest od poziomu izolacji transakcji.
> To stwierdzenie jest nie do końca poprawne, imho, ponieważ tak naprawdę
> blokada nie nic wspólnego z użytkownikiem, a z transakcją. ;-)
> A że każdy user pracuje (bo musi) na bazie w kontekście różnych
> transakcji, to tak ludziska to opisują. No, ale to wg mnie skrót myślowy
> - bo taka blokada zadziała i dla tego samego usera, wystarczy odpalić
> kilka transakcji/sesji :)
Masz rację. Jakoś dzisiaj ma problem z formułowaniem wypowiedzi (patrz
update po całej tabeli).
--
Tomek Dzięcioł
jasiek_poducha
No niewiem czy nie przekombinowaliście, przecież chodzi tylko o to by dwaj
uzytkownicy /czytaj dwie transakcje/ nie dokonywały w tym samym czacie zmian
w rekordzie jednym i tylko jednym a nie na całej tabeli.
To czy w tym samym czasie na rekordzie 10 i rekordzie 122 jest dokonywana
zmiana to dla oznaczonosci stanów tabeli nie ma znaczenia natomiast gdy by
chcieć w tym samym czasie dokonywac zmian na rekordzie np. 13 przez dwie
transakcje to jest problem który z userów czytaj transakcji jest wazniejsza.
a przez to ma piereszeństwo w realizacji. Głownym celem wprowadzenia
transakcji była zasada robimy wszytko albo nic dopiero przy okazji niejako
wyszła sprawa mozliwosci blokowania zmian na tych samych rekordach. Choć
niektórzy rozwiazali to po przez piorytety. Reasumując, otwieramy transakcję
by nie dac mozliwości innym dokonywania zmian w tym samym czasie i
natychmiast zamykamy transakcje by te zmiany innym umozliwić... to tak na
moje chłopskie zrozumienie sprawy. Więc jak czytam o mozliwości blokowaniu
całych tabel to się pytam ..po co to ?
pozdrawiam
jasiek
wloochacz
> No niewiem czy nie przekombinowali�cie, przecie� chodzi tylko o to by dwaj
> uzytkownicy /czytaj dwie transakcje/ nie dokonywa�y w tym samym czacie zmian
> w rekordzie jednym i tylko jednym a nie na ca�ej tabeli.
> To czy w tym samym czasie na rekordzie 10 i rekordzie 122 jest dokonywana
> chcieďż˝ w tym samym czasie dokonywac zmian na rekordzie np. 13 przez dwie
> transakcje to jest problem kt�ry z user�w czytaj transakcji jest wazniejsza.
> a przez to ma pieresze�stwo w realizacji. G�ownym celem wprowadzenia
> transakcji by�a zasada robimy wszytko albo nic dopiero przy okazji niejako
> wysz�a sprawa mozliwosci blokowania zmian na tych samych rekordach. Cho�
> niekt�rzy rozwiazali to po przez piorytety.
Co dok�adnie masz na my�li pisz�c o priorytetach?
> Reasumuj�c, otwieramy transakcj�
> by nie dac mozliwo�ci innym dokonywania zmian w tym samym czasie i
> natychmiast zamykamy transakcje by te zmiany innym umozliwiďż˝... to tak na
> moje ch�opskie zrozumienie sprawy. Wi�c jak czytam o mozliwo�ci blokowaniu
> ca�ych tabel to si� pytam ..po co to ?
No to przeczytaj jeszcze raz.
I jeszcze raz.
A na ko�cu mo�e zrozumiesz, �e kolega Tomasz si� pomyli�, pisz�c
przyk�adowy kod SQL, co zauwa�y� Morff, a czego ja nie zauwa�y�em.
Poza tym nikt nie pisaďż˝ o blokowaniu tabel sensu stricte, tylko o
b��dnym UPDATE Tomasza, kt�re w efekcie zablokuje wszystkie rekordy w
tabeli.
I nie CA�� tabel�, bo np. nadal b�dzie mo�na dopisywa� do niej rekordy.
--
wloochacz
jasiek_poducha
> Co dokładnie masz na myśli pisząc o priorytetach?
>
kłania się system baz rozprosznych
> A na końcu może zrozumiesz, że kolega Tomasz się pomylił, pisząc
> przykładowy kod SQL, co zauważył Morff, a czego ja nie zauważyłem.
> Poza tym nikt nie pisał o blokowaniu tabel sensu stricte, tylko o błędnym
> UPDATE Tomasza, które w efekcie zablokuje wszystkie rekordy w tabeli.
> I nie CAŁĄ tabelę, bo np. nadal będzie można dopisywać do niej rekordy.
masz rację moja pomyłka ale to nie zmienia wymowy wywodu jezeli blokujemy
wybrany rekord na czas edycji to czym żesz to jest, jak nie zdublowaniem tej
samej operacji. W pierwszym kroku blokujemy po przez wykonanie update które
nic w sumie nie robi samo siebie zmienia i to na kluczu ID /jezeli to jest
klucz/ a w drugim etapie dokonujemy zmiany na powiedzmy 3 polu tabeli i
konczymy transakcje / tak sie domyslam/ więc po grzyba wykonywac ta pierwszą
operacje ? Kiedy otworzenie dla tej drugiej operacji transakcji wykona to
samo: uniemozliwi innemu userowi zmian w updatowanym rekordzie :(.
Strata czasu, obciazenie łacza, a i mozliwośc przypału ...user wszedł se do
tabeli rozpoczoł zmiane blokując rekord i se poszedł ....na tydzień na
zwolnienie i co ? transakcja wsi ..rekord zablokowany. Jak by nie dumał ...
pytanie aktualne a po co to ?
pozdrawiam
jasiek
Adam Siwoń
> [...]
A słyszał Ty o problemie straconej modyfikacji? Najprostszym sposobem
jego rozwiązania jest właśnie nałożenie blokady przed rozpoczęciem
edycji... Oczywiście można stosować strategię optymistyczną ale jak ktoś
lubi pesymistyczną?
--
z pozdrowieniami
Adam Siwoń
wloochacz
>>
> kłania się system baz rozprosznych
Bo z tego co wiem, a raczej z tego co się domyślam z Twojej lakonicznej
wypowiedzi, to masz na myśli to, że do transakcji można przypisać
określony priorytet.
Można, ale mówimy to o transakcjach w bazach danych. A nie o
transakcjach w silnikach (pn. MTS, TXSeries) do przetwarzania transakcji
rozproszonych (nie baz rozproszonych; to nie muszą być bazy danych sensu
stricte), bo właśnie tam istnieje takie pojęcie jak priorytet transakcji.
W bazie danych transakcja ma znacznik czasowy, w efekcie czego działa na
zasadzie - kto pierwszy ten lepszy.
Tak czy owak, nie ma to żadnego związku z tematem.
>> A na końcu może zrozumiesz, że kolega Tomasz się pomylił, pisząc
>> przykładowy kod SQL, co zauważył Morff, a czego ja nie zauważyłem.
>> Poza tym nikt nie pisał o blokowaniu tabel sensu stricte, tylko o błędnym
>> UPDATE Tomasza, które w efekcie zablokuje wszystkie rekordy w tabeli.
>> I nie CAŁĄ tabelę, bo np. nadal będzie można dopisywać do niej rekordy.
>
> masz rację moja pomyłka ale to nie zmienia wymowy wywodu jezeli blokujemy
> wybrany rekord na czas edycji to czym żesz to jest, jak nie zdublowaniem tej
> samej operacji. W pierwszym kroku blokujemy po przez wykonanie update które
> nic w sumie nie robi samo siebie zmienia i to na kluczu ID /jezeli to jest
> klucz/ a w drugim etapie dokonujemy zmiany na powiedzmy 3 polu tabeli i
> konczymy transakcje / tak sie domyslam/ więc po grzyba wykonywac ta pierwszą
> operacje ? Kiedy otworzenie dla tej drugiej operacji transakcji wykona to
> samo: uniemozliwi innemu userowi zmian w updatowanym rekordzie :(.
Niezupełnie; tu nam tu opisujesz system optymistycznego blokowania, a my
cały czas rozmawiamy o blokowaniu pesymistycznym.
Różnica jest i to istotna; trzeba doczytać...
> Strata czasu, obciazenie łacza, a i mozliwośc przypału ...user wszedł se do
> tabeli rozpoczoł zmiane blokując rekord i se poszedł ....na tydzień na
> zwolnienie i co ? transakcja wsi ..rekord zablokowany. Jak by nie dumał ...
> pytanie aktualne a po co to ?
Właśnie po to, żeby ten rekord zablokować w sposób pesymistyczny; czyli
przed rozpoczęciem zmiany (update, delete) blokuję rekord dla siebie,
aplikacja robi co musi, wysyła odpowiednie polecenie do serwera i
zdejmuje blokadę.
Problem "wiszących" blokad w takim przypadku będzie zawsze i są różne
metody ich rozwiązywania; zazwyczaj jest to timeout, np, w MS SQL jest
wielce pożyteczne polecenie SET LOCK_TIMEOUT; domyślnie wyłączone, czyli
blokada czeka aż do jej zwolnienia.
Przy braku mechanizmu blokowania, każdy może rozpocząć zmianę dowolnej
informacji nie wiedząc o tym, że ktoś już wcześniej rozpoczął jej
edycję, a w bazie danych pojawią się ostatnie zmiany; no i mamy "fajne
jaja"...
--
wloochacz
humanista (mruczus)
> Np. tak:
> UPDATE tabela SET id = id;
Takie blokady stosowano przy użyciu ibexpress bo inaczej transakcje w ogóle
nie działały i nazywa się pesymistyczne blokowanie. Przy dbexpress to nie
jest potrzebne. Drugi użytkownik może edytować jednocześnie i dopiero
zatwierdzenie zmian przez jednego z nich blokuje innych użytkowników w taki
sposób że jeśli oni próbują zatwierdzić zmiany to dostają wyjątek z
transakcji. To jest optymistyczne blokowanie, stosowane najczęściej tzn gdy
jest mała szansa na jednoczesny zapis na tym samym rekordzie w dużej bazie
danych.
wloochacz
Tak - jest to pesymistyczne blokowanie.
Nie, bo "inaczej transakcje w ogóle nie działały" nie jest prawdą.
Działały i to dobrze.
Natomiast bzdurą jest to, że blokowanie pesymistyczne w DBX nie jest
potrzebne. Pesymistyczne blokowanie jest potrzebne zawsze, gdzie jest
potrzebne.
Jak myślisz, dlaczego jedną z nowości ADO.NET 2.x jest możliwość
blokowania pesymistycznego?
Ponieważ architekt uznał, podobnie jakTy, że taka możliwość jest
"niepotrzebna".
Odsyłam do wątku po szczegóły...
--
wloochacz
humanista (mruczus)
bo najczęściej mamy duże bazy i jednoczesny dostęp do tych samych rekordów
następuje rzadko, podczas gdy użytkownicy ibx stosują go stale.
Optymistyczne blokowanie nie spowoduje awarii bazy danych ale w bazach, w
których następuje często jednoczesny dostęp do tego samego rekordu,
przedłuży i utrudni wykonywanie operacji. Przy zakleszczeniu silnik bazy
danych sam powinien rozpoznać ten stan i wycofać jedną z czekających
transakcji automatycznie.
wloochacz
> rzadko, bo najczęściej mamy duże bazy i jednoczesny dostęp do tych
> samych rekordów następuje rzadko, podczas gdy użytkownicy ibx stosują go
> stale.
ma pesymistycznego blokowania z automatu - zresztą dotyczy to
jakichkolwiek komponentów.
W takim przypadku trzeba blokować jawnie.
> Optymistyczne blokowanie nie spowoduje awarii bazy danych ale w
> bazach, w których następuje często jednoczesny dostęp do tego samego
> rekordu, przedłuży i utrudni wykonywanie operacji. Przy zakleszczeniu
> silnik bazy danych sam powinien rozpoznać ten stan i wycofać jedną z
> czekających transakcji automatycznie.
Nie chodzi o deadlocki, tylko o problem utraconej modyfikacji.
A to jest sytuacja, którą wygodnie i pewnie można obsłużyć za pomocą
pessmisting locking - niezależnie od użytej technologii dostępowej i
serwera bazy danych.
Sam używam permanentnie mechanizmu CachedUpdates i blokowania
optymistycznego. Ale tam gdzie to niezbędne, blokuję pesymistycznie.
--
wloochacz
Norbert
> Sam używam permanentnie mechanizmu CachedUpdates i blokowania
> optymistycznego. Ale tam gdzie to niezbędne, blokuję pesymistycznie.
A np. gdzie jest to niezbedne?
--
pozdrawiam
Norbert
humanista (mruczus)
rekordów które zmienią się przez zapis innego użytkownika. Jeśli te
zmienione rekordy posłużą do obliczeń to wyniki będą niezgodne z aktualnym
stanem bazy. Przy obliczeniach ekonomicznych to będzie tragedia.
Przypuśćmy że użytkownik czyta dane w transakcji z dwóch tabel przez dwa
zapytania select. Po pierwszym odczycie drugi użytkownik zmienia dane w tych
tabelach ale pierwszy uzytkownik nie widzi zmian w pierwszej tabeli, widzi
tylko zmiany w drugiej tabeli bo zdążył ją odczytać. Optymistyczne
blokowanie w interbase i dbexpress ustawia się jako ReadCommited.
W przedstawionej sytuacji radzono mi albo połączyć tabele żeby było jedno
select (podobno wtedy nie występuje ten problem ale nie jestem pewien) albo
stosować blokowanie typu RepeatableRead, ale przy tym ostatnim przy użyciu
clientdataset miałem problemy takie, że mimo wycofania transakcji nie dało
się już nic zapisać do tego rekordu. Może był błąd w bibliotekach? Nie wiem.
W końcu zostałem bez wyjaśnienia co robić w takiej sytuacji.
wloochacz
>> Sam używam permanentnie mechanizmu CachedUpdates i blokowania
>> optymistycznego. Ale tam gdzie to niezbędne, blokuję pesymistycznie.
>
> A np. gdzie jest to niezbedne?
transakcji, że nie informacja została zablokowana do edycji.
"Niezbędność" określam z użytkownikiem - on określa, ja ustawiam "toto"
w systemie.
Podobnie zresztą jak wymagalność pól; to co jest not null to oczywiśćie
wymagalne jest, ale użytkownik może sam określić że jakiś atrybut jest
wymagalny ponad to. Bez rekompilacji app, zmian w bazie danych, etc.
--
wloochacz