Por padrão, o Oracle usa nível de linha fechaduras.
Esses bloqueios estão bloqueando apenas para escritores (atualizar, excluir, inserir etc). Isso significa que o select funcionará o tempo todo quando uma tabela for atualizada pesadamente, excluir de, etc.
Por exemplo, seja tableA(col1 number, col2 number), com estes dados dentro dele:
col1 | col2
1 | 10
2 | 20
3 | 30
Se o usuário John apresentar problemas em
time1 :update tableA set col2=11 where col1=1;
bloqueará a linha1.
Às
time2 usuário Mark emitir um update tableA set col2=22 where col1=2;
a atualização funcionará, pois a linha 2 não está bloqueada.
Agora a tabela procura no banco de dados:
col1 | col2
1 | 11 --locked by john
2 | 22 --locked by mark
3 | 30
Para Mark a tabela é (ele não vê as alterações não confirmadas)
col1 | col2
1 | 10
2 | 22
3 | 30
Para John a tabela é:(ele não vê as alterações não confirmadas)
col1 | col2
1 | 11
2 | 20
3 | 30
Se mark tentar em
time3 :update tableA set col2=12 where col1=1;
a sessão dele ficará suspensa até
time4 quando John emitirá um commit .(A reversão também desbloqueará as linhas, mas as alterações serão perdidas) tabela é (em db, em time4):
col1 | col2
1 | 11
2 | 22 --locked by mark
3 | 30
Imediatamente, após o commit de John, o row1 é desbloqueado e a atualização de marks fará o trabalho:
col1 | col2
1 | 12 --locked by mark
2 | 22 --locked by mark
3 | 30
vamos marcar a emissão de um rollbak em time5:
col1 | col2
1 | 11
2 | 20
3 | 30
O caso de inserção é mais simples, porque as linhas inseridas são bloqueadas, mas também não são vistas por outros usuários porque não são confirmadas. Quando o usuário confirma, ele também libera os bloqueios, para que outros usuários possam visualizar essas linhas, atualizá-las ou excluí-las.
EDITAR :Como Jeffrey Kemp explicou, quando você tem PK (é implementado no Oracle com um índice único), se os usuários tentarem inserir o mesmo valor (assim, teríamos uma duplicata), o bloqueio acontecerá no índice . A segunda sessão ficará bloqueada até que a primeira sessão termine porque ela tenta escrever no mesmo lugar. Se a primeira sessão for confirmada, a segunda lançará a exceção de violação de chave primária e falhará ao alterar o banco de dados. Se a primeira sessão fizer uma reversão, a segunda será bem-sucedida (se nenhum outro problema aparecer).
(NB:nesta explicação pelo usuário John refiro-me a uma sessão iniciada pelo usuário John.)
