Odp: Re: Exclusive-lock i transakcja

["Siergiej Szablykin" <SSzablykin@lukas.com.pl>]

  Sprawa wyglada nastepujaco:
1. Przy podlaczeniu do bazy przez siec lub pamiec dzielona transakcja nie jest startowana.
2. Jezeli w petli w procedurze wywolamy kolejne procedury i gdziekolwiek wystapi blad, to nic sie nie cofa bo nie ma zadnej transakcji.
3. Transakcji na kliencie, moim zdaniem, powinne obejmowac trosze wiecej niz transakcyjny zapis do bazy, np. transakcje zwiazane z temp-table'ami. Natomiast taka "osobliwosc" kompilacji ciagnie sie (na ile pamiec mnie nie zawodzi) od wersji 7

Kawalek kodu z przykladem:
/********************************/
def var i as int.
def var ln as int.


select max(cust-num) into ln from customer.
ln = ln + 1.

bl:
for first _file exclusive-lock:
  message transaction
    view-as alert-box.
  run c(ln).
  undo bl, leave bl.
end.

select count(*) into i from customer where customer.cust-num = ln.
message i
  view-as alert-box.

run a.

select count(*) into i from customer where customer.cust-num = ln.
message i
  view-as alert-box.

procedure a:
  bl-p:
  for first _file exclusive-lock /*transaction*/ :
    message transaction
      view-as alert-box.
    run c(ln).
    undo bl-p, leave bl-p.
  end.
end procedure.


procedure c:
def input parameter nr as integer.

  create customer.
  assign
    customer.cust-num = nr
  .
end procedure.

/********************************/


>>> tomasz.fidecki@jms.com.pl 00-08-29 12:19 >>>
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 
------
------
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
------