Controle de Concorrncia em Transaes lvaro Vincius de

Controle de Concorrência em Transações Álvaro Vinícius de Souza Coêlho alvaro. degas@yahoo. com. br

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

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

Controle de Concorrência • • T 1 lê o saldo T 1. Quant = 15 T 2 lê o saldo T 2. Quant = 15

Controle de Concorrência • Tanto para T 1 quanto para T 2 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 (Dead. Lock) • Casos excepcionais • Um conjunto de transações pode ficar em espera eterna

Controle de Concorrência • Exemplo: – Uma transação T 1 de venda bloqueará a tabela Cliente e em seguida a tabela Estoque – Uma transação T 2 de compra bloqueará a tabela Estoque e em seguida a tabela Contas – Uma transação T 3 de cobrança bloqueará a tabela Contas e em seguida a tabela Cliente

Controle de Concorrência • • T 1 inicia, e bloqueia a tabela Cliente T 2 inicia, e bloqueia a tabela Estoque T 3 inicia, e bloqueia a tabela Contas T 1 está esperando pela tabela Estoque T 2 está esperando pela tabela Contas T 3 está esperando pela tabela Cliente Dead. Lock

Controle de Concorrência • Como resolver? • Duas estratégias: – Detectar o Dead. Lock – Prevenir o Dead. Lock

Controle de Concorrência • Detectar o Dead. Lock – Periodicamente (na menor fração de tempo possível sem comprometer a performance) verificar dependências entre transações, formando um grafo T 1 T 2 T 3

Controle de Concorrência • Detectar o Dead. Lock – Caso o grafo forme um Ciclo, há a verificação de um Dead. Lock – 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 Dead. Lock – Para cada tentativa de bloqueio, o SGBD constrói o grafo de dependência a priori – Caso o bloqueio venha a causar Dead. Lock, 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 Dead. Lock é 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 Dead. Lock – Evita o custo de desfazê-los • Detectar é melhor se há poucas ocorrências de Dead. Lock – 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 Manet