De forma predeterminada, Oracle usa nivel de fila cerraduras.
Estos bloqueos solo bloquean a los escritores (actualizar, eliminar, insertar, etc.). Eso significa que select funcionará todo el tiempo cuando una tabla se actualice mucho, se elimine, etc.
Por ejemplo, sea tableA(número col1, número col2), con estos datos dentro:
col1 | col2
1 | 10
2 | 20
3 | 30
Si el usuario John emite en time1 :
update tableA set col2=11 where col1=1;
bloqueará la fila 1.
A las time2 usuario Marca emitir un
update tableA set col2=22 where col1=2;
la actualización funcionará porque la fila 2 no está bloqueada.
Ahora la tabla se ve en la base de datos:
col1 | col2
1 | 11 --locked by john
2 | 22 --locked by mark
3 | 30
Para Mark table is(él no ve los cambios no confirmados)
col1 | col2
1 | 10
2 | 22
3 | 30
Para John, la tabla es:(él no ve los cambios no confirmados)
col1 | col2
1 | 11
2 | 20
3 | 30
Si Mark intenta en time3 :
update tableA set col2=12 where col1=1;
su sesión se colgará hasta time4 cuando John emitirá un commit .(Retroceder también desbloqueará las filas, pero los cambios se perderán)
la tabla es (en db, a la hora 4):
col1 | col2
1 | 11
2 | 22 --locked by mark
3 | 30
Inmediatamente, después de la confirmación de John, la fila 1 se desbloquea y la actualización de las marcas hará el trabajo:
col1 | col2
1 | 12 --locked by mark
2 | 22 --locked by mark
3 | 30
marquemos emitir un rollbak en el momento 5:
col1 | col2
1 | 11
2 | 20
3 | 30
El caso de inserción es más simple, porque las filas insertadas están bloqueadas, pero otros usuarios tampoco las ven porque no están confirmadas. Cuando el usuario confirma, también libera los bloqueos, por lo que otros usuarios pueden ver estas filas, actualizarlas o eliminarlas.
EDITAR :Como explicó Jeffrey Kemp, cuando tiene PK (se implementa en Oracle con un índice único), si los usuarios intentan insertar el mismo valor (entonces, tendríamos un duplicado), el bloqueo ocurrirá en el índice . La segunda sesión se bloqueará hasta que finalice la primera sesión porque intenta escribir en el mismo lugar. Si la primera sesión se confirma, la segunda arrojará una excepción de clave principal violada y no podrá cambiar la base de datos. Si la primera sesión realiza una reversión, la segunda tendrá éxito (si no aparece ningún otro problema).
(NB:En esta explicación del usuario John me refiero a una sesión iniciada por el usuario John).
