BD II (SI 587) Controle de Concorrência Josenildo Silva jcsilva@ifma.edu.br
Nota Estes slides são baseados nos slides disponibilizados pelos autores ELMASRI e NAVATHE, para o livro Sistemas de Banco de Dados, 6ª. Edição, Ed. Pearson Brasil. Capítulo 22. Técnicas de Controle de Concorrência.
Propósito Garantir a propriedade de isolamento em transações concorrentes Preservar a consistência do banco pela preservação da consistência de execução concorrente Resolver conflitos de leitura-gravação e gravação-gravação
Bloqueio (lock) É uma variável associada a um item de dados Descreve operações aplicáveis ao item de dados Geralmente há um bloqueio para cada item no BD
Bloqueio (lock) Principais tipos de bloqueios: Bloqueio binário Bloqueio compartilhado/exclusivo
Bloqueio binário Pode ter dois estados: bloqueado e desbloqueado São simples, mas também muito restritivos Não são usados na prática.
Bloqueio binário - Algoritmo
Bloqueio binário - regras
Bloqueio binário As regras são impostas pelo módulo gerenciador de bloqueio do SGBD. Entre as operações lock_item(x) e unlock_item(x) na transação T, diz-se que T mantém o bloqueio no item X. No máximo, uma transação pode manter um bloqueio em determinado item.
Bloqueio compartilhado/exclusivo Permite mais concorrência que o bloqueio binário Oferece mais flexibilidade
Bloqueio Compartilhado/Exclusivo - operações read-lock(x) Antes de read(x), se ainda não tiver read-lock ou write-lock write-lock(x) Antes de read(x) com intenção de write(x), ou antes de write(x) se ainda não tiver write-lock unlock(x) Depois de todas as operações de read(x) e write(x)
Bloqueio compartilhado/exclusivo - regras
Bloqueio compartilhado/exclusivo - regras
Bloqueio compartilhado/exclusivo - algoritmo
Bloqueio compartilhado/exclusivo - algoritmo
Bloqueio compartilhado/exclusivo - algoritmo
Serialização por bloqueio em duas fases Em uma transação todas as operações de bloqueio (read_lock, write_lock) precedem a primeira operação de desbloqueio na transação
Serialização por bloqueio em duas fases Fase de expansão ou crescimento (primeira), durante a qual novos bloqueios em itens podem ser adquiridos, mas nenhum pode ser liberado; Fase de encolhimento (segunda), durante a qual os bloqueios existentes podem ser liberados, mas nenhum novo bloqueio pode ser adquirido.
Exemplo: Transações sem Bloqueio em duas fases As transações T 1 e T 2, a seguir, não seguem o protocolo de bloqueio em duas fases
Exemplo: Transações sem Bloqueio em duas fases Valores iniciais X=20 e Y=30 T1 seguido por T2: X=50 e Y=80 T2 seguido por T1: X=70 e Y=50
Exemplo: Transações sem Bloqueio em duas fases
Exemplo com bloqueio em duas fases
Serialização por bloqueio em duas fases O bloqueio em duas fases pode limitar a quantidade de concorrência uma transação T pode não ser capaz de liberar um item X depois de usálo se T tiver de bloquear um item adicional Y depois
Serialização por bloqueio em duas fases Reciprocamente, T precisa bloquear um item adicional Y antes que precise dele, de modo que possa liberar X. Logo, X precisa permanecer bloqueado por T até que todos os itens que a transação precisa ler ou gravar tenham sido bloqueados; somente então X pode ser liberado por T.
Problemas com serialização em duas fases Impasse (deadlock) Bloqueio circular Inanição (starvation) Espera infinita
Deadlocks em bloqueio de duas fases
Tratamento de deadlocks Sem espera (no waiting) Espera cautelosa (cautious waiting) Baseado em Grafo (wait-for) Tempo expirado Esperar ou morrer (wait-die) Ferir-ou-esperar (wound-wait)
Tratamento de deadlocks Sem espera (no waiting) Se uma transação não conseguir um bloqueio, ela é abortada imediatamente. Espera cautelosa (cautious waiting) Só aguarda o bloqueio de um item X se ele estiver sendo utilizado por uma transação que não está bloqueada.
Tratamento de Deadlocks Pode-se demonstrar que a espera cautelosa é livre de deadlock, pois nenhuma transação esperará por outra transação bloqueada.
Tratamento de deadlocks Grafo de espera (wait-for) Manter um grafo com arestas T i --> T j se T i aguarda um item bloqueado por T j Um deadlock acontece se houver um ciclo neste grafo Seleção de vítimas (mais novas)
Tratamento de deadlocks Tempo expirado Se uma transação esperar por um período de tempo limite (timeout) definido pelo sistema a transação é reiniciada
Tratamento de deadlocks Algumas técnicas de tratamento de deadlocks utilizam o conceito de rótulo de tempo (timestamp) da transação TS(T) é um identificador único TS(T 1 ) < TS(T 2 ) se T 1 é mais antiga
Tratamento de Deadlocks Esperar ou morrer Se TS(T i ) < TS(T j ), T i pode esperar, senão, será reiniciado com o mesmo TS. Ferir ou esperar Se TS(T i ) < TS(T j ), T j é reiniciado com o mesmo TS, senão T j pode esperar.
Tratamento de Deadlocks Esperar ou morrer e Ferir ou esperar abortam a transação mais nova Ambos também evitam o problema de starvation, pois mantém o TS original da transação abortada
Controle de concorrência com rótulo de tempo O uso de bloqueios, combinado com o protocolo 2PL, garante a serialização de schedules. Os schedules serializáveis produzidos pelo 2PL têm seus schedules seriais equivalentes com base na ordem em que as transações em execução bloqueiam os itens que elas adquirem.
Serialização por bloqueio em duas fases O algoritmo de ordenação de rótulo de tempo (timestamp) A ideia é ordenar as transações com base em seus rótulos de tempo. O schedule serial equivalente tem as transações na ordem de seus valores de rótulo de tempo.
Ordenação de rótulo de tempo
Ordenação de rótulo do tempo básica
Ordenação de rótulo do tempo básica
Ordenação de rótulo de tempo (TO) estrito Bloqueia todos os itens a ser lidos/gravados antes de iniciar a transação Livre de deadlock Exige pré declaração (leitura/gravação) no início da transação Inanição (starvation) pode acontecer se uma transação for continuamente abortada ou reiniciada
Ordenação de rótulo de tempo Estrito e Rigoroso 2PL Estrito Não libera bloqueios de escrita até o commit ou abort da transação A transação T só lê e/ou grava valores que foram alterados por transações que já realizaram commit
Ordenação de rótulo de tempo Estrito e Rigoroso 2PL Rigoroso (caso específico do estrito) Não libera bloqueios de leitura e escrita até o commit ou abort da transação Mais fácil de implementar que o estrito
Ordenação de rótulo de tempo Estrito e Rigoroso Livres de rollback em cascata Porém, diminui bastante o nível de concorrência
Controle de concorrência multiversão (MVCC) Alguns protocolos para controle de concorrência mantêm os valores antigos de um item de dados quando este é atualizado. Eles são conhecidos como controle de concorrência multiversão Diversas versões de um item são mantidas. Quando uma transação requer acesso a um item, uma versão apropriada é escolhida
Multiversão com rótulo do tempo Nesse método, diversas versões X1, X2,..., Xk de cada item de dados X são mantidas. Para cada versão, o valor da versão Xi e os dois rótulos de tempo a seguir são mantidos:
Multiversão com rótulo do tempo
Controle de concorrência multiversão (MVCC) Sempre que uma transação T tem permissão para executar uma operação write_item(x), uma nova versão X K+1 do item X é criada, e tanto write_ts(x k+1 ) quanto read_ts(x k+1 ) são definidos como TS(T) Quando uma transação tem T tem permissão para ler o valor da versão X i, o valor de read_ts(x) é definido como sendo o maior dentre o read_ts(x i ) atual e TS(T)
Compatibilidade de bloqueios