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
- O linie este `zavorata' INAINTE ca orice schimbare sa apara pe
ecran.
- nu sunteti anuntat
- la alte incercari de a actualiza aceeasi linie se primeste
anunt
- Alti utilizatori pot actualiza diferite linii din aceeasi tabela.
- Dupa ce o actualizare este terminata, lock-urile sunt anulate.
- Cand incercati sa actualizati o inregistrare care s-a schimbat
de cand ati consultat-o ultima oare:
- apare un mesaj de avertisment
- trebuie sa reconsultati linia inainte de a o actualiza.
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:
- lock-urile DML anulate
- lock-urile DDL pastrate
In rezumat, un COMMIT care reuseste:
- Schimba modul de lock pe tabela
- Protejeaza pe durata modificarii bazei de date
- 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)
- NU este necesar sa zavorati explicit nici o tabela
- DAR puteti emite instructiuni explicite de lock dintr-un trigger
- Select ... for update ... da posibilitatea sa cititi si sa
`zavorati' simultan o linie
- Exclusive mode anunta pe ceilalti de actualizarea tabelei
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 ?
- Select ... for update - va pemite sa cititi si sa `zavorati'
simultan. Aceasta inseamna ca puteti verifica datele inainte de
a face orice schimbare.
- 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.
- 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:
- Enter_Querry (cu parametru `for_update')
- Execute_Querry ( cu parametru `for_update')
- Lock_Record
Utilizatorul poate zavora direct o inregistrare selectand optiunea
`Lock' din submeniul `Record'.
ON-LOCK Trigger
- Inlocuieste Lockingul la nivel de linie in SQL*Forms
- Se activeaza cand utilizatorul incearca actualizarea/stergerea
liniei ne-"zavorate".
- Include :
- determinarea inregistrarilor care pot fi modificate
- micsorarea ovearhead-ului introdus de locking
- Procedura package "Lock_Record" este utila in aplicarea de lockuri
pe linii in On-Lock trigger.
- Trebuie fie sa blocheze accesul la inregistrare, fie sa esueze !
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 !