Controle de transações

Os sistemas gerenciadores de banco de dados (SGBD) precisam conter uma série de requisitos para que possam funcionar de maneira correta.

Antes de tudo, é necessário entender que transações são todas as operações executadas entre o início e fim de cada transação.

ACID

O ACID, acrônimo de Atomicidade, Consistência, Isolamento e Durabilidade descrevem as propriedades necessárias em cada transação para garantir o bom funcionamento de um banco de dados.

A atomicidade se refere a transações atômicas, ou seja, ou todas as ações são executadas, ou nenhuma. Isso quer dizer que se em uma transação há três operações nas quais duas foram bem sucedidas e uma não, então a atomicidade deve garantir que nenhuma delas sejam executadas, ou caso já tenham executado (COMMIT), é necessário que a operação seja desfeita (ROLLBACK).

Já a consistência deve garantir que todas as operações de cada transação não afeta a consistência do banco de dados, em outras palavras, nenhuma operação deve gerar problemas no que já está contido no banco de dados.

Por sua vez, o isolamento se refere a individualidade de cada transação, ou seja, cada transação deve ser isolada dos efeitos da execução concorrente de outras transações.

E por fim a durabilidade deve garantir que toda transação finalizada de forma bem sucedida persista seus resultados em banco, mesmo na presença de falhas no sistema.

Dada as especificações de cada propriedade do ACID, somos capazes de detectar problemas no banco, ao analisar se nas operações há falta de uma ou mais propriedades. O ACID nos permite detectar problemas, porém para evitá-los utilizamos o controle de transações, que visa construir algo que garanta o isolamento e a consistência das transações.

Bloqueio Binário

As operações podem ser tanto de leitura quanto de escrita, e para que não haja conflito, usamos o bloqueio como solução. O bloqueio está associado a um item de dado no qual podemos definir o que poderemos ou não fazer com o item bloqueado.

Um dos métodos desenvolvidos para realização do bloqueio é o Bloqueio binário, que é um método booleano onde usamos (1) para Lock e (0) Unlock.

Controle de transações - 5

O algoritmo acima parece simples mas não é trivial, pois a lógica do bloqueio consiste em:

Quem chegar primeiro bloqueia.

Se quero bloquear, preciso saber se já está bloqueado

  1. Não bloqueado: Seto para (1) Lock
  2. Bloqueado: Espero até que o Lock volte a ser (0).

Para garantir o funcionamento existe um gerenciador de transações responsável por informar a quem está em espera que o Lock foi desbloqueado, porém este aviso não garante a realização da transação, e sim a possibilidade de tentar novamente. Neste intervalo, pode ser que outro chegue a frente ou pode haver uma fila.

O problema dessa solução é que nem todas as operações realizadas devem bloquear o acesso a todos. O que quero dizer é que se a operação for apenas de leitura, o acesso poderá ser compartilhado a outros usuários, e apenas quando a operação for de escrita que deverei bloqueá-la para a execução de somente uma transação.

Para solucionar este problema cria-se então dois Locks:

  1. Leitura: Todos podem ler
  2. Gravação: Apenas um pode gravar

E damos o nome a estes Locks de bloqueio compartilhado ou exclusivo.

O bloqueio compartilhado (SharedLock) é utilizado para leitura, onde podem haver transações simultâneas que impedem a requisição de um bloqueio exclusivo.

Já o bloqueio exclusivo (Exclusive Lock) é utilizado para gravação e somente uma transação poderá solicitá-lo por vez.

Matriz de compatibilidade:

Controle de transações - 4

Para garantir o funcionamento do bloqueio compartilhado/exclusivo existe um gerenciador de bloqueios que gerencia o bloqueio de cada item e mantém uma tabela de controle.

Segundo Elmasri, 2007 a tabela consiste em:

Controle(“Quem realiza a transação”, “Qual o item”, “Qual o modo”, “Quem é o próximo item”)

Os algoritimos abaixo foram retirados do livro Sistemas de Banco de Dados – Elmasri Navathe e descrevem como é realizada a operação ReadLock (Bloqueio compartilhado) e WriteLock (Bloqueio exclusivo).

Operação ReadLock:

Controle de transações - 3

Operação WriteLock:

Controle de transações - 2

Já a operação de Unlock (Desbloqueio) depende do estado que estamos, caso seja em Whrite-Locked sabemos que há apenas uma transação sendo executada, porém se estiver em Read-Locked poderá haver várias transações sendo executadas simultaneamente, por isso a regra é decrementar o número de transações que estão bloqueando, e se chegar em (0) então o Lock ficará desbloqueado e o próximo da fila será informado.

Veja o exemplo segundo Elmasri, 2010:

Controle de transações - 1

O controle de concorrência e o método de bloqueio evitam problemas porém não acaba com eles, o que quero dizer é que, mesmo utilizando o método de bloqueio ainda sim pode haver casos em que ocorrerá erros.

Um dos possiveis problemas é conhecido como DeadLock, que acontece quando duas ou mais tarefas bloqueiam uma à outra permanentemente, sendo que cada uma tem o bloqueio de um recurso que a outra tarefa está tentando bloquear.

Por exemplo, Transação A mantem um bloqueio em algumas linhas na tabela de Contas e precisa atualizar algumas linhas na tabela Pedidos para terminar. Transação B mantém bloqueios sobre essas mesmas linhas na tabela Pedidos, mas necessita de atualizar as linhas na tabela de Contas bloqueadas pela transação A. Transação A não pode completar a sua transação por causa do bloqueio em pedidos. Transação B não pode completar a sua transação por causa do bloqueio em Contas.

Com isso, as atividades de ambas permanecerão paradas a menos que o SGBD detecta o impasse e aborte uma das transações.

Concluímos então que o controle de transações é o processo de gerenciamento de execução simultânea de transações em um banco de dados compartilhado. Basicamente, o controle de concorrência garante que resultados das operações sejam corretos e executados de maneira rápida.

Referências

Fundamentals of Database Systems – by Ramez Elmasri (Author), Shamkant B. Navathe (Author)

https://docs.oracle.com/database/121/CNCPT/transact.htm#CNCPT038