|
TwojePC.pl © 2001 - 2024
|
 |
A R C H I W A L N A W I A D O M O Ś Ć |
 |
| |
|
Semafor wielostanowy w bazie danych? , maruszek 15/03/05 23:55
Problem zwiazany z bazami danych do rozgryzienia:
Mam aplikacje, w ktorej jest taka sytuacja:
- uzytkownicy wykonują wiele wspolbieznych operacji (nazwijmy je "A") robiacych "costam"
- raz na dzien musi zostac wykonana operacja "B", ktora wymaga aby zadna operacja "A" nie była w tym czasie wykonywana
Zeby takie cos zagwarantowac potrzebne jest cos w stylu semafora wielostanowego - operacja A bedzie na poczatku zwiekszala wartosc semafora o 1, a po zakonczeniu zmniejszala o 1. Problem w tym, ze takie cos na pierwszy rzut oka wydaje sie trudne do zrobienia na zwyklej bazie relacyjnej - jesli zwiekszanie i zmniejszanie wartosci semafora byloby w roznych transakcjach to mogloby dojsc do niespojnosci gdyby druga transakcja nie przeszla.
Dlatego trzeba (tak mi sie wydaje) robic wszystko w jednej transakcji (podniesienie semafora, operacja, opuszczenie semafora, commit). Tu powstaje drugi problem - takie transakcje musialyby stosowac brudne odczyty, zeby widziec na wzajem swoje zmiany (w sumie nie wiem czy to jest problem).
Pomysl jest na razie taki - transakcja B zapisuje do specjalnej tabeli ze wlasnie sie rozpoczela (wstawia jakas krotke informującą ze B chce wykonac swoją operację) i sprawdza czy trwa jakas transakcja A (czy w tej tabeli są jakies wpisy transakcji A). Jesli nie ma to robi swoje, jesli są to czeka jakistam czas i sprawdza do skutku. Transakcja A na poczatku sprawdza czy trwa B (brudny odczyt), jesli tak to sie konczy, jesli nie to zapisuje do tabeli ze wlasnie trwa A, robi swoje, po czym usuwa swoj wpis.
Da sie wymyslic cos lepszego? To rozwiazanie nie jest w 100% skuteczne, ale w normalnych warunkach nie powinno sie wysypac. Inna sprawa ze troche bedzie z tym mieszania.
dziekiUmieść posta na Brodzie - jesli jest to problem do rozwiazania w praktyce i na bazie oracle to polecam pakiet , bwana 16/03/05 06:59
DBMS_LOCK, sluzy do tworzenia 'zmiennych' ktore sa widoczne dla wszystkich sesji. Podejrzewam, ze odpowiednik na MS SQL Server tez istnieje, podobnie jak pewnie na wiekszosci dojrzalych systemow bazodanowych.
Jesli jednak chcesz sie oprzec na transakcjach, to przyjrzyj sie (mowie nadal o bazie Oracle, bo te baze znam, na swojej szukaj analogii) pragmie pakietowej AUTONOMOUS_TRANSACTION - transakcja autonomiczna tudziez asynchroniczna, czyli taka, ktora mozna zaczac w trakcie trwania 'glownej' transakcji i zakonczyc zatwierdzeniem mimo wycofania transakcji 'glownej'. Przynajmniej czesc wspomnianych przez Ciebie problemow rozwiazaloby utworzenie pakietu/procedur przykladowo:
podnies_semafor(semafor in varchar2)
pragma autonomous_transaction;
begin
...
commit;
end;
i
podnies_semafor(semafor in varchar2)
pragma autonomous_transaction;
begin
...
commit;
end;
Jednakowoz rozwiazanie z uzyciem DBMS_LOCK wydaje mi sie juz na pierwszy rzut oka wydajniejsze."you don't need your smile when I cut
your throat" - są jeszcze inne nie bazodanowe , szarp 16/03/05 08:14
rozwiązania czyli semafory, pamięć współdzielona
swoją drogą twoje rozwiązania wydaje się być ok ale jest trochę pracochłonne i mało wydajne. Nie lepiej zrobić to tak że chwilowo wyłączasz dostęp do tej tablicy i szybciutko przelatujesz te rekordy i znowu włączasz?KS - wszystko (jesli chodzi o wydajnosc) jest kwestia wolumenu transakcji oraz kalkulacji , bwana 16/03/05 09:19
kosztu wykonania. Jesli aktualizacje wykonywane beda od wielkiego dzwonu, statystycznie - przez jedna sesje w danym czasie, pewnie najprosciej jest zablokowac na czas transakcji cala tabele.
Inaczej sprawa ma sie w sytuacji, gdy transakcje o ktorych pisze Maruszek maja byc wykonywane czesto i rownolegle przez wielu uzytkownikow (sesji). Wtedy blokowanie calej tabeli moze okazac sie zbyt kosztowne pod wzgledem wydajnosci, a akceptowalne moze okazac sie blokowanie (zapisu/odczytu/wstawiania) okreslonej populacji rekordow (np. tylko rekordow zwiazanych z danym klientem w bazie, z dana faktura, z danym pracownikiem).
Smiem upierac sie przy stwierdzeniu, ze skalowalnosc rozwiazania z blokowaniem calej tabeli jest zerowa - oczywiscie to nie jest przeszkoda w sytuacji gdy mamy pewnosc, ze liczba uzytkownikow (lub liczba funkcji aplikacji zwiazanych z danymi w takiej tabeli) nie wzrosnie znaczaco."you don't need your smile when I cut
your throat" - zgadzam się w całej , szarp 16/03/05 14:29
rozciągłości ... jeśli proces B jest sotunkowo prosty i rzadko wykonywany a danych jest mało - blokujemy tablicę lub jej jakieś obszary, w każdym innym przypadku mamy problemKS
- W praktyce nie pomoge, ale... , MARC 16/03/05 12:41
Teoretyczne rozwiazanie twojego problemu to chyba algorytm czytelnikow i pisarzy. Najpierw wielu cos moze robic rownolegle, a potem trzebe jednego wpuscic, w momencie gdy nikt inny nic nie robi.
Poszukaj informacji o tym algorytmie i zobacz, czy sie nada. Powinien byc tak, czy inaczej, realizowalny w wiekszosci rozwiazan programistycznych.
|
|
|
|
 |
All rights reserved ® Copyright and Design 2001-2024, TwojePC.PL |
 |
|
|
|
