Problemas de transações simultâneas

1.1 Introdução

E agora começa a diversão - a teoria de como as transações funcionam. Como manter o sistema funcionando quando você altera os mesmos dados em threads diferentes? Ou você quer executar uma transação em outra? Começaremos a buscar respostas para essas perguntas estudando o isolamento das transações ...

O nível de isolamento da transação é um valor condicional que determina até que ponto, como resultado da execução de transações logicamente paralelas no DBMS, dados inconsistentes são permitidos. A escala dos níveis de isolamento da transação contém vários valores, classificados do menor ao maior; um nível de isolamento mais alto corresponde a uma melhor consistência de dados, mas seu uso pode reduzir o número de transações fisicamente paralelas.

Por outro lado, um nível de isolamento inferior permite mais transações paralelas, mas reduz a precisão dos dados. Assim, escolhendo o nível de isolamento da transação utilizado, o desenvolvedor do sistema de informação, de certa forma, oferece uma escolha entre a velocidade do trabalho e a garantia da consistência dos dados recebidos do sistema.

Problemas de acesso concorrente usando transações

Quando as transações são executadas em paralelo, os seguintes problemas são possíveis:

• atualização perdida - se um bloco de dados for alterado simultaneamente por diferentes transações, todas as alterações serão perdidas, exceto a última;
• leitura "dirty" (eng. Dirty read) - leitura de dados adicionados ou alterados por uma transação, que posteriormente não será confirmada (revertida);
• leitura não repetível (eng. leitura não repetível) - ao reler dentro da mesma transação, os dados lidos anteriormente são alterados;
• leituras fantasmas - uma transação durante sua execução várias vezes seleciona muitas linhas de acordo com os mesmos critérios. Outra transação entre essas buscas adiciona linhas ou modifica colunas de algumas das linhas usadas nos critérios de busca da primeira transação e termina com sucesso. Como resultado, as mesmas seleções na primeira transação resultarão em diferentes conjuntos de linhas.

Considere situações em que esses problemas podem ocorrer.

1.2 Atualização perdida

A situação em que, quando um bloco de dados é alterado simultaneamente por diferentes transações, uma das alterações é perdida.

Suponha que haja duas transações em execução ao mesmo tempo:

Em ambas as transações, o valor do campo f2 muda, após a conclusão, o valor do campo deve ser aumentado em 45. De fato, a seguinte sequência de ações pode ocorrer:

1. Ambas as transações leem simultaneamente o estado atual do campo. A simultaneidade física exata não é necessária aqui, basta que a segunda operação de leitura em ordem seja concluída antes que outra transação grave seu resultado.
2. Ambas as transações calculam o novo valor do campo adicionando 20 e 25, respectivamente, ao valor lido anteriormente.
3. As transações tentam gravar o resultado do cálculo de volta no campo f2. Como é fisicamente impossível realizar duas gravações ao mesmo tempo, na realidade uma das operações de gravação será executada antes e a outra mais tarde. A segunda operação de gravação substituirá o resultado da primeira.

Como resultado, o valor do campo f2, após a conclusão de ambas as transações, pode aumentar não em 45, mas em 20 ou 25, ou seja, uma das transações de alteração de dados “desaparecerá”.

1.3 Leitura "suja"

Leitura de dados adicionados ou modificados por uma transação que posteriormente falhará ao confirmar (reversão).

Suponha que temos duas transações abertas por aplicativos diferentes que executam as seguintes instruções SQL:

Na transação 1, o valor do campo f2 é alterado e, na transação 2, o valor deste campo é selecionado. Depois disso, é feito o rollback da transação 1. Como resultado, o valor recebido pela segunda transação será diferente do valor armazenado no banco de dados.

1.4 Leitura não repetível

A situação quando, ao reler dentro da mesma transação, os dados lidos anteriormente acabam sendo alterados.

Suponha que temos duas transações abertas por aplicativos diferentes que executam as seguintes instruções SQL:

Na transação 2, o valor do campo f2 é selecionado, então na transação 1, o valor do campo f2 é alterado. Se você tentar selecionar novamente um valor do campo f2 na transação 2, um resultado diferente será obtido. Essa situação é especialmente inaceitável quando os dados são lidos para modificá-los parcialmente e gravá-los de volta no banco de dados.

1.5 Lendo "fantasmas"

A situação quando, durante a leitura repetida dentro da mesma transação, a mesma seleção fornece diferentes conjuntos de linhas.

Suponha que existam duas transações abertas por aplicativos diferentes que executam as seguintes instruções SQL:

A transação 2 executa uma instrução SQL que usa todos os valores do campo f2. Em seguida, uma nova linha é inserida na transação 1, fazendo com que a reexecução da instrução SQL na transação 2 produza um resultado diferente. Essa situação é chamada de leitura fantasma (phantom reading). Difere da leitura não repetível porque o resultado do acesso repetido aos dados mudou não devido à alteração/exclusão dos próprios dados, mas devido ao aparecimento de novos dados (fantasmas).