🚀 go-pugleaf

Jarek Zgoda napisał(a) w wiadomości: <3715CA78.F35A7F92@kki.net.pl>...
|Pytam o to ponownie - jakis czas temu nikt nie udzielił ni ma nie
|odpowiedzi na pl.comp.lang.delphi.
|Chodzi mi o to, żeby sprawdzić, czy rekord jest w danej chwili blokowany
|(Interbase 4.2). Jeżeli tak, to jego edycja byłaby niemożliwa, a jeżeli
|nie, to byłby blokowany i użytkownik mógłby rozpocząć edycję. W tej
|chwili jest tak, że pomimo blokady (otwarcia transakcji), drugi
|użytkownik może uruchomić edycję rekordu, a jedynie próba zapisu
|wprowadzonych zmian jest niemożliwa. Dodatkowo, gdy ktos inny dokona
|zmian, następne zmiany są odrzucane. Już wiem, że nie będzie prosto, ale
|może ktos mnie oswieci?
|Jarek Zgoda


Ja tez sie z tym meczylem.Niby Interbase ma cos takiego jak dynamiczne
blokowanie ,ale wlasnie objawia sie to jak powyzej. W tej chwili rozwiazalem
to w ten sposob, ze dodalem sobie pole typu bool (domena locked smallint z
check=0 or 1) i
przed rozpoczeciem edycji sprawdzam, czy pole jest true.Jezeli tak, to
message do usera, zeby poczekal , probowal za chwile.
Jezeli masz na serwerze storedproc ,to tez to musisz uwzglednic.
Jest to uciazliwe w chiwli, jezeli ktos np. zacznie edycje rekordu i pojdzie
np. do kibelka na 30 min.
Mozna tez zrobic sobie view z opcja select * from x where polelocked=1, ale
wtedy tych zablokowanych nie bedzie widac.


psujak@friko7.onet.pl

Psujak wrote:

> Ja tez sie z tym meczylem.Niby Interbase ma cos takiego jak dynamiczne
> blokowanie ,ale wlasnie objawia sie to jak powyzej. W tej chwili rozwiazalem
> to w ten sposob, ze dodalem sobie pole typu bool (domena locked smallint z
> check=0 or 1) i
> przed rozpoczeciem edycji sprawdzam, czy pole jest true.Jezeli tak, to
> message do usera, zeby poczekal , probowal za chwile.
> Jezeli masz na serwerze storedproc ,to tez to musisz uwzglednic.
> Jest to uciazliwe w chiwli, jezeli ktos np. zacznie edycje rekordu i pojdzie
> np. do kibelka na 30 min.
> Mozna tez zrobic sobie view z opcja select * from x where polelocked=1, ale
> wtedy tych zablokowanych nie bedzie widac.

Rozwiązanie interesujące. Nie wiesz jednak, jak sprawa wygląda, gdy
aplikacja padnie w trakcie edycji (spadek napięcia, zawis windy,
cokolwiek)? Czy nie jest tak, że wartosć true zostaje w tym polu i
trzeba ją później ręcznie usuwać?
Jarek Zgoda

Jarek Zgoda <jzgoda@kki.net.pl> napisał(a):
>Rozwiązanie interesujące. Nie wiesz jednak, jak sprawa wygląda, gdy
>aplikacja padnie w trakcie edycji (spadek napięcia, zawis windy,
>cokolwiek)? Czy nie jest tak, że wartosć true zostaje w tym polu i
>trzeba ją później ręcznie usuwać?

Zamiast Boolean można dać numer końcówki. Przy starcie końcówka
powinna najpierw kasować wszystkie swoje wpisy. Powinno działać pod
jednym warunkiem: po padzie końcówkę należy podnieść aby blokada nie
była zbyt długa.
-- 
Marcin Wieczorek ( T-1000 )
wieczor@polbox.com 
DELPHI FAQ http://delphi.koti.com.pl

Jarek Zgoda napisał(a) w wiadomości: <3716F300.5FADE1EF@kki.net.pl>...
|
|Rozwiązanie interesujące. Nie wiesz jednak, jak sprawa wygląda, gdy
|aplikacja padnie w trakcie edycji (spadek napięcia, zawis windy,
|cokolwiek)? Czy nie jest tak, że wartosć true zostaje w tym polu i
|trzeba ją później ręcznie usuwać?
|Jarek Zgoda

Psujak wrote:
Jezeli aplikacja jawnie rozpocznie transakcje (Start transaction) a wartosc
drivera SqlPassThruMode=SharedNoAutoCommit , to juz sam Interbase zadba
sobie o padanie koncowek itd.Po prostu nie dostanie EndTransaction czy
Commit i wysle wszystkie zmiany na ksiezyc.
Jedyny problem moze powstac w momencie, gdy padnie maszyna na ktorej jest
Interbase, ale na to nkt jeszcze nie wymyslil madrego i pewnego sposobu.

psujak@friko7.onet.pl

Psujak <psujak@friko7.onet.pl> napisał(a) w artykule
<ujBR2.1955$O1.27094@news.tpnet.pl>...
> Ja tez sie z tym meczylem.Niby Interbase ma cos takiego jak dynamiczne
> blokowanie ,ale wlasnie objawia sie to jak powyzej. W tej chwili
rozwiazalem
> to w ten sposob, ze dodalem sobie pole typu bool (domena locked smallint
z
> check=0 or 1) i
> przed rozpoczeciem edycji sprawdzam, czy pole jest true.Jezeli tak, to
> message do usera, zeby poczekal , probowal za chwile.
> Jezeli masz na serwerze storedproc ,to tez to musisz uwzglednic.
> Jest to uciazliwe w chiwli, jezeli ktos np. zacznie edycje rekordu i
pojdzie
> np. do kibelka na 30 min.
> Mozna tez zrobic sobie view z opcja select * from x where polelocked=1,
ale
> wtedy tych zablokowanych nie bedzie widac.

W InterBase'ie zastosowano metody blokowania optymistycznego. Samo
otworzenie transakcji i przejście do edycji jednego z wierszy uzyskanego w
wyniku zapytania nie powoduje zablokowania rekordu. A dlaczego? Dlatego, że
serwer nie wie, że jest wykonywana edycja rekordu. Wszystkie operacje
dzieją się na stacji roboczej, która musi powiadomić serwer o chęci
zablokowania rekordu i uzyskać na to jego zgodę lub nie. To co stosuje
Psujak to właśnie jest wykorzystanie blokowania InterBase'a. Jeśli dodaje
on pole do tabeli, którą edytują użytkownicy, a następnie zmienia jego
wartość, to próba zablokowania tego samego rekordu przez inną transakcje
skończy się informacją o błędzie zakleszczenia transakcji (deadlock). Na
tym właśnie polega blokowanie rekordów, a nie na wpisywaniu wartości! Nawet
jeśli Psujak przy wchodzeniu do edycji nadpisywałby pole wartością 0, a nie
1 to i tak rekord będzie zablokowany dla innych transakcji (użytkowników).
Inaczej trzeba by tylko było obsłużyć sprawdzanie blokady. Blokadę sprawdza
się przez jej założenie! Jeśli się nie uda i wystąpi deadlock, to znaczy,
że rekord jest zablokowany, a jeśli założenie blokady się powiedzie, to
rekord można edytować. 
Mam nadzieję, że treść nie jest zbyt agresywna. Zapraszam do dyskusji na
ten temat.

Traptak

17 Apr 1999 14:33:20 +0100, "Traptak" <gidex@gryf.com.pl> napisał(a):

>Mam nadzieję, że treść nie jest zbyt agresywna. Zapraszam do dyskusji na
>ten temat.

nie każdy lock is dead

|Inaczej trzeba by tylko było obsłużyć sprawdzanie blokady. Blokadę sprawdza
|się przez jej założenie! Jeśli się nie uda i wystąpi deadlock, to znaczy,
|że rekord jest zablokowany, a jeśli założenie blokady się powiedzie, to
|rekord można edytować.
[Psujak]
Wszystko to madrze brzmi, ale jak to wyglada w praktyce. Bo moze jest to
sposob, ale jego minus ,to jest to, iz objawia sie w momencie zapisu, a nie
rozpoczecia edycji.
|Mam nadzieję, że treść nie jest zbyt agresywna. Zapraszam do dyskusji na
|ten temat.
[Psujak]
Spoko jest.
|Traptak

Mon, 19 Apr 1999 08:26:38 +0200, Jarek Zgoda <jzgoda@kki.net.pl>
napisał(a):

>> W InterBase'ie zastosowano metody blokowania optymistycznego. Samo
>> otworzenie transakcji i przejście do edycji jednego z wierszy uzyskanego w
>> wyniku zapytania nie powoduje zablokowania rekordu. A dlaczego? Dlatego, że
>> serwer nie wie, że jest wykonywana edycja rekordu. Wszystkie operacje
>> dzieją się na stacji roboczej, która musi powiadomić serwer o chęci
>> zablokowania rekordu i uzyskać na to jego zgodę lub nie. To co stosuje
>> Psujak to właśnie jest wykorzystanie blokowania InterBase'a. Jeśli dodaje
>> on pole do tabeli, którą edytują użytkownicy, a następnie zmienia jego
>> wartość, to próba zablokowania tego samego rekordu przez inną transakcje
>> skończy się informacją o błędzie zakleszczenia transakcji (deadlock). Na
>> tym właśnie polega blokowanie rekordów, a nie na wpisywaniu wartości! Nawet
>> jeśli Psujak przy wchodzeniu do edycji nadpisywałby pole wartością 0, a nie
>> 1 to i tak rekord będzie zablokowany dla innych transakcji (użytkowników).
>> Inaczej trzeba by tylko było obsłużyć sprawdzanie blokady. Blokadę sprawdza
>> się przez jej założenie! Jeśli się nie uda i wystąpi deadlock, to znaczy,
>> że rekord jest zablokowany, a jeśli założenie blokady się powiedzie, to
>> rekord można edytować.
>> Mam nadzieję, że treść nie jest zbyt agresywna. Zapraszam do dyskusji na
>> ten temat.
>
>Swietnie. Czyli - nic sie nie da zrobić? 

przecie napisał jak to zrobić

>A chodziło mi tylko o to, jak
>sprawdzić, czy żądanie blokady będzie przez serwer rozpatrzone
>pozytywnie...  

po co ?! możesz po prostu użyć serwera

>Dowiedziałem się własnie, że IB od wersji 4 ma tabele
>systemowe, w których zapisuje dane o blokowaniu wierszy. Zastanawiam się
>teraz, jak te informacje wykorzystać w praktyce. Wolałbym, żeby
>niepowołane końcówki nie miały dostępu do tabel systemowych.

to bez sensu, dostęp do nich jest asynchroniczny, serwer w każdej
chwili może zmienić zawartość i ty nie możesz się nią kierować bo może
nie być już aktualna, tak samo ustawianie pola z wartością bool jest
asynchroniczne, nim klient otrzyma informacje, że jest wolne może być
zajęte i odwrotnie, nim klient stwierdzi, że jest zajęte będzie już
wolne, poza tym nie musisz

Mon, 19 Apr 1999 09:00:06 +0200, "Psujak" <psujak@friko7.onet.pl>
napisał(a):

>|Inaczej trzeba by tylko było obsłużyć sprawdzanie blokady. Blokadę sprawdza
>|się przez jej założenie! Jeśli się nie uda i wystąpi deadlock, to znaczy,
>|że rekord jest zablokowany, a jeśli założenie blokady się powiedzie, to
>|rekord można edytować.
>[Psujak]
>Wszystko to madrze brzmi, ale jak to wyglada w praktyce. Bo moze jest to
>sposob, ale jego minus ,to jest to, iz objawia sie w momencie zapisu, a nie
>rozpoczecia edycji.

kiedy nikt ci nie broni wykonania zapisu wstępnego, blokującego rekord
aż do zakończenia transakcji

Robin Wschód wrote:
 
> to bez sensu, dostęp do nich jest asynchroniczny, serwer w każdej
> chwili może zmienić zawartość i ty nie możesz się nią kierować bo może
> nie być już aktualna, tak samo ustawianie pola z wartością bool jest
> asynchroniczne, nim klient otrzyma informacje, że jest wolne może być
> zajęte i odwrotnie, nim klient stwierdzi, że jest zajęte będzie już
> wolne, poza tym nie musisz

Przepraszam, że rozpocząłem temat - wzięło się z ignorancji w dziedzinie
projektowania aplikacji. Po kilku lekturach postanowiłem zostawić
kwestię blokowania serwerowi, za to kwestię konfliktów rozwiązałem
inaczej (zgodnie z zaleceniami):
- minimalizacja czasu trwania transakcji (tylko tyle, ile jest konieczne
dla dokonania zmian)
- ustawienie parametru transakcji na WAIT (ponowienie próby dokonania
zmian po pewnym czasie).
Dziękuję za wszelkie informacje i pomoc.
Jarek Zgoda

|kiedy nikt ci nie broni wykonania zapisu wstępnego, blokującego rekord
|aż do zakończenia transakcji
|
Ale jak sie to robi ?
Czy jest to zwykle Edit ?

Psujak <psujak@friko7.onet.pl> napisał(a) w artykule
<8eVS2.10582$Lj.158749@news.tpnet.pl>...
> |kiedy nikt ci nie broni wykonania zapisu wstępnego, blokującego rekord
> |aż do zakończenia transakcji
> |
> Ale jak sie to robi ?
> Czy jest to zwykle Edit ?

Ja wykonuję operację UPDATE przy pomocy oddzielnego TQuery. Możesz to
umieścić w zdarzeniu BeforeEdit.

Traptak

Psujak <psujak@friko7.onet.pl> napisał(a) w artykule
<rnAS2.7575$Lj.100130@news.tpnet.pl>...
> |Inaczej trzeba by tylko było obsłużyć sprawdzanie blokady. Blokadę
sprawdza
> |się przez jej założenie! Jeśli się nie uda i wystąpi deadlock, to
znaczy,
> |że rekord jest zablokowany, a jeśli założenie blokady się powiedzie, to
> |rekord można edytować.
> [Psujak]
> Wszystko to madrze brzmi, ale jak to wyglada w praktyce. Bo moze jest to
> sposob, ale jego minus ,to jest to, iz objawia sie w momencie zapisu, a
nie
> rozpoczecia edycji.

Cieszę się, że to mądrze brzmi. Nie jestem tylko teoretykiem.

Traptak

Jarek Zgoda <jzgoda@kki.net.pl> napisał(a) w artykule
<371C1C71.39899307@kki.net.pl>...
> Robin Wschód wrote:
>  
> Przepraszam, że rozpocząłem temat - wzięło się z ignorancji w dziedzinie
> projektowania aplikacji. Po kilku lekturach postanowiłem zostawić
> kwestię blokowania serwerowi, za to kwestię konfliktów rozwiązałem
> inaczej (zgodnie z zaleceniami):
> - minimalizacja czasu trwania transakcji (tylko tyle, ile jest konieczne
> dla dokonania zmian)
> - ustawienie parametru transakcji na WAIT (ponowienie próby dokonania
> zmian po pewnym czasie).

Użytkownicy nie przychodzą do Ciebie z maczugą w dłoni? Blokowanie rekordów
na prawdę nie jest takie trudne. Odpowiadałem na Twój post na grupie
delphi. Ten tutaj jest jak najbardziej na miejscu. Jeśli chcesz mogę się
poświęcić i przesłać Ci na priva przykład blokowania rekordu w sposób jaki
opisywałem.

Traptak

Traptak napisał(a):

> Użytkownicy nie przychodzą do Ciebie z maczugą w dłoni? Blokowanie rekordów
> na prawdę nie jest takie trudne. Odpowiadałem na Twój post na grupie
> delphi. Ten tutaj jest jak najbardziej na miejscu. Jeśli chcesz mogę się
> poświęcić i przesłać Ci na priva przykład blokowania rekordu w sposób jaki
> opisywałem.

Ja myślę, że JESZCZE nie przychodzą - to mój pierwszy większy projekt, a
w ogóle pierwszy w systemie C/S.
Jeżeli możesz, to podeślij ten przykład - nie dlatego, żeby mi
zaoszczędzić roboty, tylko żebym po tym projekcie miał trochę włosów na
głowie :-)
Pozdrawiam
Jarek Zgoda