Pergunta

A table abaixo mostra duas transações concorrentes rodando em um db Oracle. Quando o tempo chega no ponto 16, o resultado retornado pelo select na sessão A inclui o registro criado (e commited) pela sessão B?

Resposta

O resultado não inclui o registro criado pela Sessão B.

Isto acontece porquê por default Oracle usa consistência em nível de statement, o que assegura que data visível para um statement (select, neste caso) não muda durante a “vida” deste statement.

Este comportamento (ou isolation level, como é mais formalmente conhecido) pode ser explicitamente definido na sessão corrente através do uso do comando SET TRANSACTION ISOLATION LEVEL READ COMMITED.

Consistência pode ser assegurada também em nível de transação. Neste caso, Oracle garante que qualquer comando da transação corrente vai enxergar o banco de dados como ele existia no início da transação. Neste caso, a aplicação deve definir o isolation level com o comando SET TRANSACTION ISOLATION LEVEL SERIALIZABLE.

Consistência em nível de transação também pode ser usado em situações em que apesar de não haver comandos DML (insert, delete, update) há uma sequência de statements read-only que devem enxergar o banco de dados como ele estava no início desta sequência de selects. Oracle chama isto de read-only transactions (mas acho esta nomenclatura particularmente amarga de engolir).

Nestes casos, pode-se usar o comando SET TRANSACTION READ ONLY. Apesar de não haver DML nesta sequência de operações é necessário o uso de um COMMIT ou ROLLBACK ao final da mesma.

Na sequência abaixo, o uso deste isolation level assegura que os dados retornados por ambos selects sejam coerentes entre si em um dado momento no tempo (inÍcio da transação). Em outras, palavras: evita que transações do tipo TT1 sejam também recuperadas pelo segundo select, o que provavelmente é o que o desenvolvedor tinha em mente.

O entendimento dos diferentes níveis de isolamento e dos mecanismos de gerenciamento de transação e concorrência são fundamentais para a construção de aplicações 100% confiáveis. Enganos nesta área podem levar a aplicações que funcionam “quase sempre” mas que são extremamente difíceis de depurar na hora em que resultados incoerentes são detectados.

[Home] [IT] [Oracle/Db] [SD] [PM] [Lendas Corporativas] [Diversas] [The Secret of Life] [About IT talks]