[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Exclusive-lock i transakcja
Marek Prokop wrote:
>
> Rzeczywiscie cos tu jest nie tak na moj chlopski rozum.
> Konia z rzedem temu kto to wyjasni.
> W rzeczywistosci - jak sie uruchomi wspolbieznie ten program dla dwoch uzytkownikow - rekordy sa blokowane prawidlowo (co mozna sprawdzic takze w promonie). Prawdopodobnie zakres transakcji jest tez prawidlowy (tego co prawda nie sprawdzilem).
>
> Wyglada na to, ze
> - kompilator niezgodnie z dokumentacja (blednie) w tym przypadku okresla statyczny zakres transakcji
> - funkcja TRANSACTION w tym przypadku dziala niezgodnie z dokumentacja (blednie).
>
> Dla silniejszego efektu w podprocedurze "a" mozna zmienic FIRST na EACH.
> Kompilator (v. 9.1A Windows) tez nie wychodzi na tym najlepiej, co mozna zobaczyc na zalaczonym listingu.
>
> Marek Prokop
> P.S. Powyzsze opinie sa moimi prywatnymi i nie sa oficjalnym stanowiskiem PROGRESS SOFTWARE Sp. z o. o.,
> ktorej jestem pracownikiem.
>
> .\p2.p 08/29/2000 09:17:25 PROGRESS(R) Page 1
>
> {} Line Blk
> -- ---- ---
> 1 /********************************/
> 2 1 for first customer exclusive-lock:
> 3 1 message transaction
> 4 1 view-as alert-box.
> 5 end.
> 6
> 7 run a.
> 8
> 9 procedure a:
> 10 1 for each customer exclusive-lock /*transaction*/ :
> 11 1 message transaction
> 12 1 view-as alert-box.
> 13 end.
> 14 end procedure.
> .\p2.p 08/29/2000 09:17:25 PROGRESS(R) Page 2
>
> File Name Line Blk. Type Tran Blk. Label
> -------------------- ---- --------- ---- --------------------------------
> .\p2.p 9 Procedure No Procedure a
> .\p2.p 10 For No
> .\p2.p 0 Procedure No
> Buffers: sports.Customer
>
> .\p2.p 2 For Yes
>
Moim zdaniem ewidenty błąd. No chyba, że jesteśmy świadkami ewolucji kompilatora
i swego rodzaju optymalizacji procesu wyszukiwania potencjalnych transakcji.
Bowiem faktycznie w pętli "for" w procedurze "a" nic się nie dzieje z rekordem
customer. Gorzej, że jeśli damy w bloku "for" np. "display customer.name", to w
listingu nadal nie zobaczymy, że jest to traktowane jako potencjalna transakcja.
Dopiero polecenie typu assign lub update przekonuje kompilator do tego, by
potraktował blok jako transakcję. Sam więc sobie obaliłem tezę o ewolucji ;-)))
Dlatego jest to raczej materiał na kolejne, tak liczne łatki.
Grozy dodaje fakt, że debugger też nie widzi transakcji (pewnie korzysta z
funkcji TRANSACTION) ;-)))
pozdrawiam
--
Tomasz Fidecki
JMS Serwis Sp. z o.o. ul. Instalatorów 7c 02-237 Warsaw Poland
phone +48 22 846 47 81 mobile +48 501 136 122 mailto:tfidecki@jms.com.pl
------
Strona WWW: http://pluton.pol.lublin.pl/pugpl/index.htm
Obsluga listy: listserv@zeto.bydgoszcz.pl
Archiwum listy: http://www.zeto.bydgoszcz.pl/progress/index.html
------