Controle de Concorrência em Transações Álvaro Vinícius de Souza Coêlho

Controle de Concorrência Na prática várias transações estão acessando, alterando, incluindo e excluindo dados ao mesmo tempo Isso pode gerar uma série de anomalias

Uma transaçao T1 faz uma venda de 10 unidades de um certo item Uma transação T2 idem Neste dado momento o saldo disponível em estoque é de 15 unidades Controle de Concorrência

T1 lê o saldo T1.Quant = 15 T2 lê o saldo T2.Quant = 15 Controle de Concorrência

Tanto para T1 quanto para T2 a operação é permitida Mas uma das duas vai esbarrar no subsistema de integridade! (check saldo >= 0) Outras anomalias podem ocorrer de maneira semelhante (leituras incorretas, perdas de atualizações, etc.) Controle de Concorrência

Bloqueio As transações bloqueiam os dados que vão alterar À medida que se faz um COMMIT ou um ROLLBACK os dados são desbloqueados Dados só podem ser bloqueados por uma transação se não já estiverem bloqueados por outra Controle de Concorrência

Porque o desbloqueio ocorre em COMMIT ou ROLLBACK? Para garantir a integridade Controle de Concorrência

Bloqueio em duas fases Para se garantir que realmente não haverão anomalias, o bloqueio deverá ser feito em duas fases. –As transações bloqueiam os dados –As transações desbloqueiam os dados As transações não bloqueiam os dados após haver algum desbloqueio Controle de Concorrência

Bloqueio Perpétuo (DeadLock) Casos excepcionais Um conjunto de transações pode ficar em espera eterna Controle de Concorrência

Exemplo: –Uma transação T1 de venda bloqueará a tabela Cliente e em seguida a tabela Estoque –Uma transação T2 de compra bloqueará a tabela Estoque e em seguida a tabela Contas –Uma transação T3 de cobrança bloqueará a tabela Contas e em seguida a tabela Cliente Controle de Concorrência

T1 inicia, e bloqueia a tabela Cliente T2 inicia, e bloqueia a tabela Estoque T3 inicia, e bloqueia a tabela Contas T1 está esperando pela tabela Estoque T2 está esperando pela tabela Contas T3 está esperando pela tabela Cliente DeadLock Controle de Concorrência

Como resolver? Duas estratégias: –Detectar o DeadLock –Prevenir o DeadLock Controle de Concorrência

Detectar o DeadLock –Periodicamente (na menor fração de tempo possível sem comprometer a performance) verificar dependências entre transações, formando um grafo T1 T3 T2 Controle de Concorrência

Detectar o DeadLock –Caso o grafo forme um Ciclo, há a verificação de um DeadLock –Neste caso, uma transação é escolhida para ser desfeita e refeita (undo e redo) A mais antiga A mais recente A que bloqueou mais recursos –A escolha varia de fabricante para fabricante Controle de Concorrência

Prevenir o DeadLock –Para cada tentativa de bloqueio, o SGBD constrói o grafo de dependência a priori –Caso o bloqueio venha a causar DeadLock, ele é atrasado por alguns instantes, e nova tentativa é feita. Controle de Concorrência

Melhor Prevenir ou Detectar (remediar)? De modo geral a prevenção demanda mais esforço –Construção de gráficos de dependência a cada tentativa de bloqueio A prevenção pode por uma transação de castigo por muito tempo - Solucionável (prioridade) Controle de Concorrência

Melhor Prevenir ou Detectar (remediar)? A Detecção –Simples, mas resolver um DeadLock é caro pois transações com muitas operações podem precisar ser desfeitas ou refeitas Pode matar uma mesma transação muitas vezes - Solucionável (troca de estratégia de escolha) Controle de Concorrência

De modo geral a regra é a seguinte: Prevenir é melhor se há muitas ocorrências de DeadLock –Evita o custo de desfazê-los Detectar é melhor se há poucas ocorrências de DeadLock –Evita o custo excessivo de construção de grafos Controle de Concorrência

FIM! Dada a Premissa: Dar presentes é melhor que Receber, eu faço o sacrifício Groucho Marx Controle de Concorrência Manet