Controle de Concorrência em
Transações
Álvaro Vinícius de Souza Coêlho
[email protected]
Controle de Concorrência
• 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 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
T2
T3
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
Manet