Per impostazione predefinita Oracle utilizza il livello di riga serrature.
Questi blocchi bloccano solo per gli autori (aggiornamento, eliminazione, inserimento ecc.). Ciò significa che select funzionerà sempre quando una tabella viene aggiornata pesantemente, eliminata da, ecc.
Ad esempio, sia tableA(numero col1, numero col2), con questi dati al suo interno:
col1 | col2
1 | 10
2 | 20
3 | 30
Se l'utente John emette problemi a time1 :
update tableA set col2=11 where col1=1;
bloccherà la riga1.
A time2 l'utente Mark emette un
update tableA set col2=22 where col1=2;
l'aggiornamento funzionerà, perché la riga 2 non è bloccata.
Ora la tabella appare nel database:
col1 | col2
1 | 11 --locked by john
2 | 22 --locked by mark
3 | 30
Per Mark la tabella è (non vede le modifiche non vincolate)
col1 | col2
1 | 10
2 | 22
3 | 30
Per John la tabella è:(non vede le modifiche senza commit)
col1 | col2
1 | 11
2 | 20
3 | 30
Se mark prova a time3 :
update tableA set col2=12 where col1=1;
la sua sessione si bloccherà fino al time4 quando John emetterà un commit .(Il rollback sbloccherà anche le righe, ma le modifiche andranno perse)
la tabella è(in db, alle ore4):
col1 | col2
1 | 11
2 | 22 --locked by mark
3 | 30
Immediatamente, dopo il commit di John, la riga1 è sbloccata e l'aggiornamento di Mark farà il suo lavoro:
col1 | col2
1 | 12 --locked by mark
2 | 22 --locked by mark
3 | 30
segniamo l'emissione di un rollbak alla volta5:
col1 | col2
1 | 11
2 | 20
3 | 30
Il caso di inserimento è più semplice, perché le righe inserite sono bloccate, ma non sono nemmeno viste da altri utenti perché non sono state salvate. Quando l'utente esegue il commit, rilascia anche i blocchi, quindi altri utenti possono visualizzare queste righe, aggiornarle o eliminarle.
MODIFICA :Come ha spiegato Jeffrey Kemp, quando hai PK (è implementato in Oracle con un indice univoco), se gli utenti provano a inserire lo stesso valore (quindi avremmo un duplicato), il blocco avverrà nel indice . La seconda sessione verrà bloccata fino al termine della prima sessione perché tenta di scrivere nello stesso posto. Se la prima sessione esegue il commit, la seconda genererà un'eccezione violata dalla chiave primaria e non riuscirà a modificare il database. Se la prima sessione esegue un rollback, la seconda avrà esito positivo (se non vengono visualizzati altri problemi).
(NB:In questa spiegazione per utente John intendo una sessione iniziata dall'utente John.)
