LOCKING IN SQL*Forms


Scopurile acestui capitol


Acast capitol este analiza modului in care SQL*Forms realizeaza locking-ul (zavorarea).

Locking-ul ete analizat atat din punctul de vedere al utilizatorului cat si din cel al proiectantului.

Dintre subiectele tratate se remarca:


Locking



Locking


Zavorarea tabelelor si a liniilor este una din actiunile esentiale in mentinerea consistentei si a integritatii bazei de date.

Simplist, zavorarea se foloseste pentru:

Orice strategie de `zavorare' implica un compromis intre scopul de a avea numar maxim de accese concurente (i.e. multi utilizatori in sistem) si necesitatea protectiei maxime a datelor.

Cand sunt necesare lock-uri ?


Lock-uri se fac oricand un utilizator incearca sa faca schimbari in baza de date.

Cand manipulati date cu SQL*Forms, schimbarile pe care le doriti sunt protejate inainte ca ele sa se produca efectiv. De fapt, oricand incercati sa scimbati un camp oarecare intr-o tabela, SQL*Forms realizeaza zavorarea' acelei linii, asigurandu-va ca nici un alt utilizator nu poate actualiza aceeasi linie pana nu ati terminat dvs. operatia pe ea.

Lock-urile NU sunt strict necesare cand accesul la baza de date este numai pentru citire. In alte cuvinte, cititorii nu cauzeaza DML lockuri in SQL*Forms. Deci, cititorii nu blocheaza niciodata accesuri la sciere si nici invers. In urmatoarele cateva pagini vom privi locking-ul din perspectiva utilizatorului, apoi vom vorbi despre ce se intampla in spatele vederilor.


Actualizari concurente cu SQL*Forms (1)


Utilizatorii A si B ruleaza fiecare o forma (**form**) personala. Utilizatorul A afiseaza toti angajatii.

 ===    Utilizatorul A schimba campul `Job' al Presedintelui King in
 |   `TEA BOY', dar nu apasa inca [Commit].
 |
 |    ___________________________________________________________________
 |   |  Action  Edit  Block  Field  Record  Querry  Help                 |
 |   | ------------- Evergreen Otter Personnel System -----------------  |
 |   |   --------------------------------------------------------------  |
 |   |  |                           User A                             | |
 |   |  |--------------------------------------------------------------| |
 |   |  | ID#   Surname  Job       Mgr#  Hired      Salary  Comm  Dept | |
 |   |  |                                                              | |
 |   |  | 7499  ALLEN    SALESMAN  7698  20 FEB 81  1600    700   30   | |
 |   |  | 7521  WARD     SALESMAN  7698  22 FEB 81  1250    500   30   | |
 |   |  | 7566  JONES    MANAGER   7839  02 APR 81  2975          20   | |
 |   |  | 7654  MARTIN   SALESMAN  7698  28 SEP 81  1250    1400  30   | |
 |   |  | 7698  BLAKE    MANAGER   7839  01 MAY 81  2850          30   | |
 |   |  | 7782  CLARK    MANAGER   7839  09 JUN 81  2450          10   | |
 |   |  | 7788  SCOTT    ANALYST   7566  09 DEC 82  3000          20   | |
 |= >|  | 7839  KING     TEA BOY         17 NOV 81  5000          10   | |
     |  | 7844  TURNER   SALESMAN  7698  08 SEP 81  1500    0     30   | |
     |  | 7876  ADAMS    CLERK     7788  12 IAN 83  1100          20   | |
     |  | 7900  JAMES    CLERK     7698  03 DEC 81   950          30   | |
     |  | 7902  FORD     ANALYST   7566  03 DEC 81  3000          20   | |
     |  | 7934  MILLER   CLERK     7782  23 IAN 82  1300          10   | |
     |   --------------------------------------------------------------  |
     |                                                                   |
     | ================================================================= |
     | Count: 15     ^v                                     Replace      |
      -------------------------------------------------------------------
        Fig 19.1: Utilizatorul A actualizeaza inregistrarea `KING'


Actualizari concurente cu SQL*Forms (2)


Utilizatorul B vizualizeaza angajatii din departamentu 10 si acum incearca sa dea Presedintelui King o marire de salariu (sau sa faca orice schimbare in inregistrarea lui).
In orice caz, utilizatorul A are rezervata linia lui King din baza de date.

In josul ecraranului utilizatorului B apare un mesaj.

(Mesajul poate varia)


      -------------------------------------------------------------------
     |  Action  Edit  Block  Field  Record  Querry  Help                 |
     |   --------------------------------------------------------------  |
     |  |                           User B                             | |
     |  |--------------------------------------------------------------| |
     |  | ID#   Surname  Job       Mgr#  Hired      Salary  Comm  Dept | |
     |  |                                                              | |
     |  | 7782  CLARK    MANAGER   7839  09 JUN 81  2450          10   | |
     |  | 7839  KING     PRESIDENT       17 NOV 81  5000          10   | |
     |  | 7934  MILLER   CLERK     7782  23 IAN 82  1300          10   | |
     |  |                                                              | |
     |  |                                                              | |
     |  |                                                              | |
     |  |                                                              | |
     |  |                                                              | |
     |  |                                                              | |
     |  |                                                              | |
     |  |                                                              | |
     |  |                                                              | |
     |  |                                                              | |
     |   --------------------------------------------------------------  |
     |                                                                   |
     | Attempting to reserve record for update or delete (^C to cancel)  |
     | Count:  *3                                         Replace        |
      -------------------------------------------------------------------
        Fig 19.2: Utilizatorul B incearca o actualizare


Dupa ce utilizatorul B apasa ^C linia de mesaj se schimba, aparand mesajul :
        FRM-40653: Record not reserved for update or delete. Try again latter.

Utilizatorul B este liber sa manipuleze orice alta inregistrare de pe ecran (presupunand ca ele nu sunt rezervate de un alt utilizator) si poate face modificarile.


Actualizari concurente cu SQL*Forms (3)


Utilizatorul A apasa [Commit]. Inregistrarea lui King este furnizata bazei de date.
      ___________________________________________________________________
     |  Action  Edit  Block  Field  Record  Querry  Help                 |
     | ------------- Evergreen Otter Personnel System -----------------  |
     |   --------------------------------------------------------------  |
     |  |                           User A                             | |
     |  |--------------------------------------------------------------| |
     |  | ID#   Surname  Job       Mgr#  Hired      Salary  Comm  Dept | |
     |  |                                                              | |
     |  | 7499  ALLEN    SALESMAN  7698  20 FEB 81  1600    700   30   | |
     |  | 7521  WARD     SALESMAN  7698  22 FEB 81  1250    500   30   | |
     |  | 7566  JONES    MANAGER   7839  02 APR 81  2975          20   | |
     |  | 7654  MARTIN   SALESMAN  7698  28 SEP 81  1250    1400  30   | |
     |  | 7698  BLAKE    MANAGER   7839  01 MAY 81  2850          30   | |
     |  | 7782  CLARK    MANAGER   7839  09 JUN 81  2450          10   | |
     |  | 7788  SCOTT    ANALYST   7566  09 DEC 82  3000          20   | |
     |  | 7839  KING     TEA BOY         17 NOV 81  5000          10   | |
     |  | 7844  TURNER   SALESMAN  7698  08 SEP 81  1500    0     30   | |
     |  | 7876  ADAMS    CLERK     7788  12 IAN 83  1100          20   | |
     |  | 7900  JAMES    CLERK     7698  03 DEC 81   950          30   | |
     |  | 7902  FORD     ANALYST   7566  03 DEC 81  3000          20   | |
     |  | 7934  MILLER   CLERK     7782  23 IAN 82  1300          10   | |
     |   --------------------------------------------------------------  |
     | ================================================================= |
     |                                                                   |
     | FRM 404000: Transaction complete -- 1 records posted and commited |
     | Count: 15     ^v                                     Replace      |
      -------------------------------------------------------------------
        Fig 19.1: Utilizatorul A realizeaza schimbarea


Inregistrarea lui King nu mai este rezervata.


Actualizari concurente cu SQL*Forms (4)


Utilizatorul B incearca din nou sa-i acorde lui King o marire de salariu. SQL*Forms detecteaza ca inregistrarea lui King afisata pe ecran nu se potriveste exact cu linia corepondenta in baza de date. Utilizatorului B i se spune se reinterogheze inregistrarea.

      -------------------------------------------------------------------
     |  Action  Edit  Block  Field  Record  Querry  Help                 |
     |   --------------------------------------------------------------  |
     |  |                           User B                             | |
     |  |--------------------------------------------------------------| |
     |  | ID#   Surname  Job       Mgr#  Hired      Salary  Comm  Dept | |
     |  |                                                              | |
     |  | 7782  CLARK    MANAGER   7839  09 JUN 81  2450          10   | |
     |  | 7839  KING     PRESIDENT       17 NOV 81  5000          10   | |
     |  | 7934  MILLER   CLERK     7782  23 IAN 82  1300          10   | |
     |  |                                                              | |
     |  |                                                              | |
     |  |                                                              | |
     |  |                                                              | |
     |  |                                                              | |
     |  |                                                              | |
     |  |                                                              | |
     |  |                                                              | |
     |  |                                                              | |
     |  |                                                              | |
     |   --------------------------------------------------------------  |
     |                                                                   |
     | FRM 40654: Record changed by another user. Re-query to see change |
     | Count:  *3                                         Replace        |
      -------------------------------------------------------------------
        Fig 19.4: Utilizatorului B e anuntat sa reiconsulte inregistrarea


Dupa ce inregistrarea este reconsultata, utilizatorul B poate continua cu marirea de salariu, daca doreste.


Locking pentru utilizator - Rezumat



Cum trateaza locking-urile SQL*Forms


Acum, dupa ce ati vazut cum e perceputa actiunea locking-ului de catre utilizator, putem anliza modul in care SQL*Forms trateaza locking-urile "in spatele vederilor".

Oracle si SQL*Forms ofera locking automat. Desi este posibil ca un trigger sau un utilizator sa obtina un lock in mod explicit, locking-ul implicit ar trebui sa fie suficient in majoritatea cazurilor.


Locking-ul (**default**) implicit in SQL*Forms


Tipurile de lock pe care le aveti la dispozitie depind de faptul ca sistemul dumneavoastra are sau nu Transaction Processing Option. Tabelul urmator arata tipurile de lock pe care le are SQL*Forms in mod implicit.

Exista disponibil un singur tip de lock pentru linie. Acesta este un lock exclusiv care asigura ca doi utilizatori nu vor resi niciodata sa actualizeze aceeasi linie in acelasi timp.

Diferit de locking-ul pentru linii, exista mai multe tipuri de locking pentru tabele. Tipul de lock in tabela ales depinde, in parte, de faptul ca versiunea dvs. de Oracle RDMBS are Transaction Process Option.


                          LOCK IN TABELA
---------------------------------------------------------------------------
                                                        Transaction
Tip de lock in tabela   Ce pot face altii ?             Processing Option ?
---------------------   -------------------             -------------------

Partejarea liniilor     sa schimbe lockurile RS             cu / fara
(Row Share)   (RS)      intr-unul din tipurile:

                        - Row Exclusive (RX)
                        - Share Row Exclusive (SRX)


Row Exclusive           - alte lockuri de tip                cu
(RX)                      RX si RS


Share Row               - alte lockuri numai de
Exclusive (SRX)           tip RS                             fara
---------------------------------------------------------------------------



                             LOCK PENTRU LINII
         -------------------------------------------------------
         Row Exclusive                  cu/fara Transaction
         (X)                            Processing Option
         -------------------------------------------------------


Despre Transaction Processing Option


Cand utilizatorii actualizeaza inregistrari pe ecran, locking-ul la nivelul tabelei este acelasi cu sau fara Transaction Processing Option. Un lock Row Share este introdus in tabela de baza a blocului ce este actualizat. Diferenta in locking pentru tabele apare in momentul executarii comenzii `commit'

Daca aveti Transaction Processing Option, mai multi utilizatori pot executa efectiv actualizari (cu `commit') simultan, pe linii diferite. Un lock Row Exclusive este pus in tabela cand utilizatorul apasa [Commit]. Alti utilizatori pot, de asemenea, sa obtina un lock Row Exclusive in aceeasi tabela.

Daca nu aveti Transaction Processing Option, Numai un utilizator poate face efectiv actualizari intr-o baza de date la un moment dat. Un lock Share Exclusive este pus in tabela cand utilizatorul apasa [Commit]. Alti utilizatori asteapta intr-o coada. Aceasta actiune este echivalenta cu obtinerea unui `completion lock' in Oracle Version 5.

Locking (**default**) implicit in SQL*Forms


                ACTUALIZARE
         -----------------------
        | 1.  Interogare        |       Fara lock-uri
        |                       |
        | 2. Schimbare pe ecran |       1. Selectie pentru actualizare
        |                       |       2. Lock pe linie (X)
        |                       |       3. Lock pe tabela (RS)
        |                       |
        | 3. [Commit]              |       Mod de lock pe tabela schimbat
         -----------------------        (RX/SRX)


                INSERARE
         -----------------------
        | 1. [Create Record]    |          Fara lock-uri
        |                       |
        | 2. Completare valori  |       Fara lock-uri
        |                       |
        | 3. [Commit]           |       Lock pe tabela (RX/SRX)
         -----------------------


                STERGERE
         -----------------------
        | 1. Interogare         |       Fara Lock-uri
        |                       |
        | 2. [Delete]              |       1. Selectie pentru actualizare
        |                       |       2. Lock pe linie (X)
        |                       |       3. Lock pe tabela (RS)
        |                       |
        | 3. [Commit]              |       Mod de lock pe tabela schimbat
         -----------------------        (RX/SRX)


Locking implicit in SQL*Forms


In cazul in care [Commit] reuseste:

In rezumat, un COMMIT care reuseste:

  1. Schimba modul de lock pe tabela
  2. Protejeaza pe durata modificarii bazei de date
  3. Anuleaza lock-urile pe linii si pe tabela, dar pastreaza lock-urile DDL.

Daca commit nu reuseste: toate lock-urile sunt pastrate.


Locking in Trigger-e


Locking-ul implicit (**default**) este:

        cu Transaction                  fara Transaction
        Processing Option               Processing Option
        -----------------               -----------------
        Row Excusive (RX)               Share Row Exclusive (SRX)


Locking in Trigger-e


Folosind versiunile anterioare de SQL*Forms si RDBMS, proiectantii de forme (forms) pun la dispozitie locking implicit in trigger-e, deoarece lockingul normal insemna `zavorarea' exclusiva a unei tabele.

Locking-ul (**default**) de baza in trigger-e nu mai este o problema in Oracle Versoin 6. Implicit, acum un trigger utilizeaza acelasi locking implicit ca si SQL*Forms; in alte cuvinte, cand se executa o INSERARE, ACTUALIZARE sau STERGERE dintr-un trigger, va fi considerat acelasi table lock ca si in SQL*Forms. adica:

        cu Transaction                          fara Transaction
        Processing Option                       Processing Option
        -----------------                       -----------------
        Row Exclusive (RX)                      Share Row Exclusive (SRX)


Aceasta inseamna ca nu este necesar sa `zavorati' o tabela in modul Share Update (Row Share mode) inainte de a emite comada INSERT, UPDATE sau DELETE intr-un trigger.

Cand ati putea dori sa emiteti comenzi de lock dintr-un trigger ?

  1. Select ... for update - va pemite sa cititi si sa `zavorati' simultan. Aceasta inseamna ca puteti verifica datele inainte de a face orice schimbare.

  2. Exclusive mode - permite sa actualizati o tabela, dar previne ceilalti utilizatori ce incearca actualizari. Lor li se permite doar citirea. Numai in circumstante deosebite ati putea dori ca un trigger sa faca un lock exclusiv.

  3. Share mode - permite doar sa cititi, opreste ceilalti utilizatori sa faca actualizari asupra tabelei pana nu anulati lock-ul. Modul partajat este util daca faceti citiri repetate; adica se garanteaza ca datele nu se schimba la citiri succesive.

Liniile pot fi `zavorate' explicit din trigger-e executand una din urmatoarele proceduri:

Utilizatorul poate zavora direct o inregistrare selectand optiunea `Lock' din submeniul `Record'.


ON-LOCK Trigger



On-Lock Trigger


On-Lock Trigger se activeaza oridecate ori SQL*Forms, in mod normal ar incerca sa zavorasca o linie. In alte cuvinte, cand utilizatorul incearca o actualizare sau stergere a unei inregistrari pe ecran.

Scop : blocheaza sau transforma intr-o `forma' (**form**)

Utilitate : Pentru aflarea inregistrarilor la care operatorul are drept de actualizare sau stergere. Pentru un sistem monoutilizator On-Lock poate micsora overheadul, baipasand complet lockingul.

        Exemplu :
        On-Lock pe EMP Block
        - - - - - - - - - - - - - - - - - - - - - - - - - -
        IF      :EMP.DEPTNO = 10 THEN
                MESSAGE ('you cannot update this record'):
                RAISE From_Trigger_Failure;
        ELSE
                LOCK_RECORD;
        END IF;
        - - - - - - - - - - - - - - - - - - - - - - - - - -


ATENTIE :


Observati utilizarea lui `Lock_Record' in exemplul anterior pentru inlocuirea functiei SQL*Forms 'locking'. La scrierea unui On-Lock trigger este important sa lansam o exceptie pentru orice inregistrare care nu doriti sa fie modificate; altfel, actualizarea/stergerea se va executa fara nici o blocare !