Módulo II: Controle de Concorrência (Aulas 1 e 7) Clodis Boscarioli
Agenda: Introdução a Controle de Concorrência; Protocolos baseados em Bloqueio; Protocolos baseados em Timestamp; Protocolos baseados em Validação; Protocolos baseados em Granularidade Múltipla; Esquemas de Multiversão; Tratamento de Deadlocks.
Introdução Uma das propriedades fundamentais de uma transação é o isolamento. Quando diversas transações são executadas de modo concorrente corre-se o risco de violar esta propriedade. É necessário que o sistema controle a interação entre transações concorrentes: esse controle é alcançado por meio de uma série de mecanismos, os quais unidos, formam o controle de concorrência. A base dos esquemas de concorrência discutidos aqui tem por base a propriedade de serialização, ou seja, todos os esquemas devem garantir que a ordenação de processamento seja serializada. Por enquanto, assumir que os sistemas não incorrem em falhas.
Protocolos com Base em Bloqueio Uma das formas de garantir que apenas escalonamentos serializáveis sejam produzidos é obrigar que o acesso aos itens de dados seja feito de maneira mutuamente exclusiva: Enquanto uma transação acessa um item de dados, nenhuma outra transação pode modificá-lo. Para implementar isso pode-se usar o método de bloqueio (lock).
Bloqueios 1. Bloqueio compartilhado: Se uma transação T i obteve um bloqueio compartilhado (denotado por S) sobre o item de dado Q, então T i pode ler, mas não escrever em Q. 2. Bloqueio exclusivo: Se uma transação T i obteve um bloqueio exclusivo (denotado por X) do item de dado Q, então T i pode tanto ler como escrever em Q. Toda transação precisa solicitar o bloqueio apropriado antes de executar qualquer operação sobre Q. Esta solicitação é feita ao controlador de concorrência. A transação só poderá executar qualquer operação sobre Q depois que controlador de concorrência conceder (grants) o bloqueio do dado à transação.
Função de Compatibilidade de Bloqueios Seja A e B uma representação arbitrária dos modos de bloqueio. Suponha que uma transação T i solicite um bloqueio do modo A sobre o item de dado Q, sobre o qual a transação T j (T i <> T j ) mantém um bloqueio do modo B. Se a transação T i conseguir o bloqueio do modo A, mesmo com a existência do bloqueio de modo B, então dize-se que o modo A é compatível com o modo B. Observe a matriz comp. Um elemento comp(a,b) da matriz possui valor verdadeiro se, e somente se, o modo A é compatível com o modo B. S X Falso S Verdadeiro Falso Falso X
Bloqueios Uma transação solicita um bloqueio: Compartilhado do item de dado Q executando a instrução lock-s(q); Exclusivo do item de dado Q executando a instrução lock-x(q); Um item de dado pode ser desbloqueado via instrução unlock(q). Uma transação pode desbloquear um item de dado a qualquer momento, mas deverá manter o bloqueio enquanto quiser operar sobre o dado.
Bloqueios T 1 : lock-x(b); read(b); B := B 50; write(b); unlock(b); lock-x(a); read(a); A := A + 50; write(a); unlock(a); T 2 : lock-s(a); read(a); unlock(a); lock-s(b); read(b); display (A + B); unlock(b); Se A = 100 e B = 200, o valor mostrado em T2 = 300.
Bloqueios T 1 T 2 Controle de concorrência lock-x(b) read(b) B := B 50 write(b); unlock(b) lock-x(a) read(a) A := A + 50 write(a) unlock(a) lock-s(a) read(a) unlock(a) lock-s(b) read(b) display(a+b) unlock(b) grant-x(b 1, T 1 ) grant-s(a 1,T 2 ) grant-s(b 1,T 2 ) grant-x(a 2,T 1 )
Bloqueios A escala de execução mostrada no slide anterior não é serializável em conflito e não é serializável em visão. A transação T 2 mostra o valor 250 dólares. A forma como os bloqueios foram concedidos permitiu que este escalonamento fosse criado. O controlador de concorrência pode impedir que escalonamentos errados sejam criados concedendo bloqueios de uma forma mais restrita. OBS.: A concessão do bloqueio, quando permitida, é feita entre o pedido de bloqueio e a execução da operação no item de dado. Assim, não serão explicitadas, nos escalonamentos, as operações de grant. Agora suponha que os desbloqueios sejam realizados no final das transações...
Bloqueios T 1 : lock-x(b); read(b); B := B 50; write(b); lock-x(a); read(a); A := A + 50; write(a); unlock(b); unlock(a); T 2 : lock-s(a); read(a); lock-s(b); read(b); display (A + B); unlock(a); unlock(b);
Bloqueios Observe que não é possível, com as transações definidas desta forma, realizar um escalonamento como mostrado anteriormente. T1 T2 Controle de concorrência lock-x(b) read(b) B := B 50 write(b); lock-x(a) lock-s(a) read(a) lock-s(b) grant-x(b 1, T 1 ) grant-s(a 1,T 2 ) Situação de deadlock.
Protocolos de bloqueio Exige-se que cada transação do sistema siga um determinado conjunto de regras, chamado de protocolo de bloqueio, indicando quando uma transação pode ou não bloquear ou desbloquear cada um dos itens de dados. Os protocolos de bloqueio restringem o número de escalas de execução possíveis. O conjunto de todas as escalas permitidas pelos protocolos de bloqueio forma um subconjunto de todas as escalas serializáveis possíveis.
Concessão de bloqueio Quando uma transação solicita bloqueio sobre um determinado item de dado em particular, e nenhuma outra transação mantém o mesmo item de dado bloqueado de modo conflitante, tal bloqueio pode ser concedido. Problema: Suponha que a transação T tenha um bloqueio compartilhado sobre Suponha que a transação T 2 tenha um bloqueio compartilhado sobre um item de dado e a transação T 1 solicite um bloqueio exclusivo do mesmo item. T 1 terá que esperar até que o bloqueio compartilhado feito por T 2 seja liberado. Enquanto isso, uma transação T 3 pode solicitar o bloqueio compartilhado sobre o mesmo item de dado. O bloqueio pedido é compatível com o bloqueio concedido a T 2, de modo que o bloqueio compartilhado pode ser concedido a T 3. Nesta altura, T 2 pode liberar o bloqueio, mas T 1 terá que esperar até que T 3 termine. Novamente, aparece uma transação T 4 que......... Logo, a transação T 1 poderá nunca ser processada, sendo então chamada de starved (ou, em starvation estagnada, em inanição).
Concessão de bloqueio Para evitar a inanição de transações... Quando uma transação T i solicita o bloqueio do item de dados Q de um modo particular M, o bloqueio é concedido, contanto que: Não haja nenhuma outra transação com bloqueio sobre Q cujo modo de bloqueio seja conflitante com M; Não haja nenhuma outra transação que esteja esperando um bloqueio sobre Q e que tenha feito sua solicitação de bloqueio antes de Ti.
Protocolo de bloqueio em duas fases Também conhecido como: Two-phase locking protocol Protocolo bi-fásico Protocolo que garante serialização. Este protocolo exige que cada transação emita suas solicitações de bloqueio e desbloqueio em duas fases: 1. Fase de expansão: uma transação pode obter bloqueios, mas não pode liberar nenhum. 2. Fase de encolhimento: uma transação pode liberar bloqueios, mas não consegue obter nenhum novo bloqueio.
Protocolo de bloqueio em duas fases As transações do slide 8 não têm duas fases. As transações do slide 11 têm duas fases. As instruções de bloqueio não precisam aparecer, necessariamente, no final da transação. Este protocolo garante serialização por conflito....
Protocolo de bloqueio em duas fases Considere qualquer transação. O ponto de escala no qual a transação obteve seu bloqueio final (o fim da fase de expansão) é chamado de ponto de bloqueio da transação. As transações podem ser ordenadas de acordo com seus pontos de bloqueio essa ordenação é, de fato, uma ordenação serializada de transações. Este protocolo não garante a ausência de deadlock.
Algumas palavras sobre recuperação Se uma transação T i falhar, por qualquer razão, é preciso desfazer seus efeitos para garantir a propriedade de atomicidade da transação. Em um sistema que permite execuções concorrentes, também é necessário assegurar que qualquer transação T j que seja dependente de T i (T j leu dados escritos por T i ) também seja abortada. Escalas de execução recuperáveis: quando a transação que é dependente de outra não é efetivada antes que a outra o seja. Escalas sem Cascata: quando para cada par de transações T i e T j, T j leia um item de dado previamente escrito por T i se T i já se efetivou.
Protocolo de bloqueio em duas fases Rollbacks em cascata podem ser evitados por uma modificação neste protocolo: Protocolo em duas fases severo: exige, em adição ao bloqueio feito em duas fases, que todos os bloqueios de modo exclusivo tomados por uma transação sejam mantidos até que a transação seja efetivada. Outra variante: Protocolo em duas fases rigoroso: exige que todos os bloqueio sejam mantidos até que a transação seja efetivada. Essas variantes são as mais usadas em implementações comerciais.
Upgrade de bloqueio Considere as transações: T 8 : read(a1), read(a2),..., read(an), write(a1) T 9 : read(a1), read(a2), display(a1+a2) Se o protocolo de bloqueio em duas fases for empregado, Se o protocolo de bloqueio em duas fases for empregado, então T 8 precisará bloquear A1 de modo exclusivo. Assim, qualquer execução concorrente de ambas as transações atinge uma execução serial. Entretanto, T 8 precisa de um bloqueio exclusivo de A1 somente ao final de sua execução, quando ela escreve A1. Assim, se T 8 estiver bloqueando A1 de modo compartilhado e depois mudar esse bloqueio para o modo exclusivo, poder-se-á obter mais concorrência.
Upgrade de bloqueio Conversão de bloqueio compartilhado para bloqueio exclusivo: upgrade Conversão de bloqueio exclusivo para bloqueio compartilhado: downgrade A promoção só pode acontecer durante a fase de expansão, e o rebaixamento só pode ocorrer durante a fase de encolhimento.
A implementação Quando uma transação T i emite uma operação read(q),o sistema emite uma instrução lock-s(q) seguida de uma instrução read(q). Quando T i emite uma operação write(q), o sistema verifica se T i ainda mantém um bloqueio compartilhado. Se ainda há, o sistema emite uma instrução upgrade(q), seguida de uma instrução write(q). De outro modo, o sistema emite uma instrução lock-x(q), seguida de uma instrução write(q). Todos os bloqueios obtidos por uma transação são desbloqueados depois da transação ser efetivada ou abortada.
Granularidade Múltipla Até agora, a referência a cada item de dado sempre foi como uma unidade à qual a sincronização é aplicada. Entretanto, diversos itens de dados podem ser tratados como uma unidade de sincronização individual. Se uma transação precisa de todo o BD, pode aplicar o bloqueio (no caso de um protocolo de bloqueio) a todo o BD, economizando na execução de código de atribuição de travas/bloqueios. O sistema pode implementar níveis múltiplos de granulação. Define-se diversos tamanhos aos itens de dados e Define-se uma hierarquia de granularidade a estes dados.
Granularidade Múltipla DB A1 A2 Fa Fb Fc Ra1 Ra2... Ran Rb1... Rbk Rc1... Rcn Quatro níveis: 1. O banco de dados como um todo; 2. Área: blocos que compõem o BD 3. Arquivo: tabelas (nenhum arquivo está em mais de uma área) 4. Registros: dados (nenhuma tupla está em mais de um arquivo)
Bloqueios Cada nó da árvore pode ter bloqueio individual (exclusivo ou compartilhado). Quando uma transação bloqueia um nó, tanto no modo compartilhado como no modo exclusivo, a transação também bloqueará todos os descendentes daquele nó no mesmo modo de bloqueio. Se uma transação bloqueia de forma explícita o arquivo F c, no modo exclusivo, então ela está bloqueando de forma implícita, no modo exclusivo, todos os registros pertencentes àquele arquivo. Se T j quiser bloquear o registro R b6 do arquivo F b, T j precisará percorrer a árvore da raiz até o registro R b6. Se algum nó do caminho estiver bloqueado de modo incompatível, então T j precisará esperar. Suponha que a transação T k queira bloquear todo o banco de dados. Para isso, ela precisa simplesmente bloquear a raiz da árvore. Entretanto, T k não deve conseguir o bloqueio, já que T i já está bloqueando parte da árvore. Inviabilidade.
Bloqueio Intencional Bloqueios intencionais serão feitos em todos os antecessores do nó antes que ele seja bloqueado de forma explícita. Assim uma transação não precisará pesquisar a árvore inteira (ou sub-árvore) se quiser bloquear um nó. Basta iniciar o percurso e verificar se existem bloqueios intencionais. Se existir, significa que itens de granularidade mais fina estão bloqueados. Neste caminho, enquanto os bloqueios intencionais não são encontrados, a transação vai deixando seus bloqueios intencionais.
Bloqueio Intencional Bloqueio intencional associado ao modo compartilhado. Bloqueio intencional associado ao modo exclusivo. Bloqueio compartilhado e intencional exclusivo. Função de compatibilidade: IS IX S SIX X IS V V V V F IX V V F F F S V F V F F SIX V F F F F X F F F F F
Protocolo de Bloqueio de Granularidade Múltipla Garante serialização. Cada transação T i pode bloquear um nó Q, usando as seguintes regras: A função de compatibilidade de bloqueio precisa ser observada; A função de compatibilidade de bloqueio precisa ser observada; A raiz da árvore precisa ser bloqueada primeiro e pode ser bloqueada em qualquer modo; Um nó Q pode ser bloqueado por T i no modo S ou IS somente se o seu pai for bloqueado por T i no modo IX ou IS. Um nó Q pode ser bloqueado por T i no modo X, SIX ou IX somente se o seu pai estiver bloqueado por T i no modo IX ou no modo SIX. T i pode bloquear um nó somente se ele não desbloqueou outro nó anteriormente (isto é, T i tem duas fases) T i pode desbloquear um nó Q somente se nenhum dos filhos de Q estiver bloqueado por T i.
Granularidade Múltipla Este protocolo exige que os bloqueios sejam feitos de cima para baixo e exige que as liberações sejam feitas de baixo par cima. Exemplo (considera a árvore do slide 25): Suponha que a transação T 1 leia o registro R a2 do arquivo F a. T 1 precisa bloquear o banco de dados, a área A 1, o arquivo F a no modo IS e, finalmente, bloquear R a2 no modo S. Suponha que a transação T 2 altere o registro R a9 do arquivo F a. T 2 precisa bloquear o banco de dados, a área A 1, o arquivo F a no modo IX e, finalmente, bloquear R a9 no modo X. Suponha que a transação T 3 leia todos os registros do arquivo F a. T 3 precisa bloquear o banco de dados e a área A 1 no modo IS e, finalmente bloquear F a no modo S. Suponha que a transação T 4 leia todo o BD. Então, poderá fazê-lo depois e bloquear o BD no modo S. T 1, T 3 e T 4 podem manter acesso ao BD concorrentemente. T 2 pode concorrer com T 1, mas não com T 3 nem com T 4.
Granularidade Múltipla Esse protocolo aumenta a concorrência e reduz o overhead por bloqueios. Útil para aplicações com: Transações curtas que mantêm acesso a poucos itens de dados; Transações longas que produzem relatório a partir de um arquivo ou de um conjunto de arquivos. O deadlock pode ocorrer.
Ordenamento por Timestamp Garante seriabilidade: Envolve o uso de timestamp para ordenar a execução das transações de forma que o escalonamento formado seja equivalente ao escalonamento serial. Timestamp: identificador único criado pelo SGBD para identificar uma transação. São associados na ordem em que as transações são submetidas ao sistema. TS(T) = timestamp da transação T. No escalonamento as transações tomam a ordem de seus timestamps Se TS(T i ) < TS(T j ), o sistema garante que o escalonamento produzido é equivalente ao escalonamento serial <T i T j >.
Algoritmo Básico Associa dois timestamps a cada item de dados X: Read_TS(X): o timestamp de leitura de X é o maior entre todos os timestamps de transações que leram X com sucesso; Write_TS(X): o timestamp de escrita de X é o maior entre todos os timestamps de transações que escreveram X com sucesso; Esses timestamps são atualizados sempre que uma instrução read(x) ou write(x) é executada. Assegura que as operações de leitura e escrita sejam executadas por ordem de timestamp.
Algoritmo Básico Exemplo Situação 1: a transação T requer uma operação de leitura. Se TS(T) < Write_TS(X), então T quer ler o valor de X que já foi sobrescrito por uma transação mais nova. Assim, a operação read é rejeitada e T é desfeita. Se TS(T) >= Write_TS(X), a transação que requer o dado é mais nova que a última que o escreveu. Assim, a operação read é executada e o Read_TS(X) recebe o maior valor entre o atual e o TS(T).
Algoritmo Básico Exemplo Situação 2: A transação T requer uma operação de escrita a. Se TS(T) < Read_TS(X), a transação é mais velha que a última transação que leu, ou seja, o valor de X que T está produzindo seria necessário antes. A operação de write é rejeitada e T é desfeita.
Algoritmo Básico Exemplo b. Se TS(T) < Write_TS(X) então T está tentando escrever um valor obsoleto em X. Logo, essa operação é rejeitada e T é desfeita. c. De outro modo, a operação write é executada e o Write_TS(X) é atualizado como TS(T).
Observações O algoritmo básico de ordenamento por timestamp checa se duas operações conflitantes ocorrem na ordem incorreta. Se sim, rejeita a última das duas operações abortando a transação que errou. Garantia da seriabilidade por conflito.
Observações Toda vez que uma transação tenta ler ou escrever um item de dado, o algoritmo compara seu timestamp com o timestamp de leitura ou escrita de X. A intenção é assegurar que o ordenamento por timestamp não seja violado. Se o ordenamento por timestamp for violado, a transação será abortada.
Observações Uma transação abortada pode, mais tarde, ser novamente submetida ao sistema como uma nova transação, e com um novo timestamp. Se T é abortada e desfeita, qualquer transação que tenha usado um valor escrito por T deve ser desfeita também. Pode cair em starvation.
Exemplo T 1 Read(B) T 2 Read(B) Read(A) display(a+b) B := B -50 Write(B) Read(A) A := A + 50 Write(A) display(a+b)
Exemplo Read Write T 1 Read(B) T 2 TS_(T 1 ) = 1 TS_(T 2 ) = 2 Read(A) display(a+b) Read(B) B := B - 50 Write(B) Read(A) A := A+ 50 Write(A) display(a+b) R_TS(B) 0 1 2 W_TS(B) 0 2 R_TS(A) 0 1 2 W_TS(A) 0 2 Op. R 1 (B) R 2 (B) W 2 (B) R 1 (A) R 2 (A) W 2 (A)
Regra de Thomas Modificação no algoritmo básico, que faz com que haja menos operações de escrita, aumentado as possibilidades de concorrência. Alteração na regra 2: Se Ts(T) < Write_TS(X), então T está tentando escrever um valor obsoleto para X. A operação de write pode ser ignorada. Deixa de garantir a seriabilidade em conflito.
Protocolos Baseados em Grafos Uma alternativa ao protocolo de duas fases; Impõem uma ordenação parcial sobre o conjunto D = {d 1, d 2,..., d n } de todos os itens de dados. Se d i d j então qualquer transação acessando d i e d j i j i j precisam acessar d i antes de acessar d j. Implica que o conjunto D pode ser visto como um grafo acíclico direcionado, chamado grafo do banco de dados. O Protocolo de Árvore é um tipo simples de protocolo de grafo.
Protocolo em Árvore
Protocolo em Árvore Somente bloqueios exclusivos são permitidos; O primeiro bloqueio por T i pode ser sobre qualquer item de dados. Subseqüentemente, um dado Q pode ser bloqueado por T i somente se o pai de Q estiver atualmente bloqueado por T i. Os itens de dados podem ser desbloqueados a qualquer tempo. Um item de dados que foi bloqueado e desbloqueado por T i não pode ser novamente bloqueado por essa mesma transação.
Protocolo em Árvore O protocolo em árvore garante serialização por conflito e assegura liberdade de deadlock. Protocolo não garante facilidade de recuperação ou liberdade de reversão em cascata: Necessita introduzir dependência de commit para garantir a recuperação. A transação pode ter que bloquear itens de dados que ela não acessa. Introduz overhead de bloqueio e, adicionalmente, tempo de espera adicional, com uma potencial diminuição na concorrência.
Protocolos baseados em Validação A execução da transação T i é feita em 3 fases: 1. Fase de Leitura e Execução: T i escreve apenas em variáveis temporárias locais, sem alteração no banco de dados real. 2. Fase de Validação: T i faz um teste de validação para determinar se variáveis locais podem ser escritas sem violar a serialização. 3. Fase de Escrita: Se T i for válida, as gravações são aplicadas no BD, caso contrário, T i é revertida. As três fases podem ser intercaladas com outras transações concorrentes, mas em cada transação devem ocorrer nessa ordem. Esse protocolo também é chamado de controle de concorrência otimista, pois baseia-se no fato de que não haverá problemas na execução da transação.
Protocolos baseados em Validação Cada transação T i tem 3 timestamps: Start(T i ): início da transação; Validation(T i ): momento em que T i entra na fase de validação; Finish(T i ): momento em que T i conclui fase de escrita. A ordem de serialização é dada pelo momento de validação. TS(T i ) = Validation(T i ). Este protocolo aumenta o grau de concorrência se a probabilidade de conflitos for baixa. Isto se dá porque a ordem de serialização não é pré-definida e, relativamente, poucas transações terão que ser desfeitas.
Protocolos baseados em Validação Se para todas as T i com TS (T i ) < TS (T j ) alguma das condições abaixo se mantém: 1. Finish(T i ) < Start(T j ) 2. Start(T j ) < Finish(T i ) < Validation(T j ) e o conjunto de itens de dados escrito por T i não possui interseção com os dados lidos por T j. então a validação termina com sucesso e T j pode ser efetivada. Caso contrário, a validação falha e T j é abortada. Justificativa: Ou a 1ª condição é satisfeita e não há execução concorrente, ou a 2ª condição é satisfeita e: as escritas de T j não afetam as leituras de T i pois ocorrem após T i terminar suas leituras. as escritas de T i não afetam as leituras de T j já que T j não lê nenhum item escrito por T i.
Esquema de Multiversão Os esquemas de controle de concorrência por bloqueio ou por timestamp garantem a serialização atrasando a operação ou abortando a transação responsável por tal operação. Essas dificuldades podem ser evitadas se o sistema providenciar cópias de cada item de dado. Em um sistema de banco de dados multiversão, cada operação write(q) cria uma nova versão de Q. Quando é emitida uma operação read(q), o sistema seleciona uma das versões de Q para ser lida. O esquema de controle de concorrência precisa garantir que a seleção da versão lida seja tal que assegure a serialização. Por razões de desempenho, uma transação precisa determinar de forma fácil e rápida qual a versão do item de dados que deverá ser utilizada.
Multiversão com Ordenação por Timestamp A cada transação T i do sistema é associado um timestamp único e estático, denotado por TS(T i ) (associado antes do início da execução da transação). Para cada item de dado Q, uma seqüência de versões <Q 1, Q 2,..., Q n > é associada. Cada versão Q k contém três campos: Content: é o valor da versão Q k ; W-timestamp(Q k ): é o timestamp da transação que criou a versão Q k. R-timestamp(Q k ): é o timestamp mais alto de alguma transação que tenha lido a versão Q k com sucesso.
Multiversão com Ordenação por Timestamp Uma transação T i cria uma nova versão Q k do item de dado Q emitindo uma operação write(q). O campo conteúdo da versão mantém o valor escrito por T i. O W-timestamp e o R-timestamp são inicializados por TS(T i ). O valor de R-timestamp é atualizado sempre que uma transação T j lê o conteúdo de Q k e R-timestamp(Q k ) <TS(T j ).
Esquema: Suponha que uma transação T i emita uma operação read(q) ou write(q). Seja Q k a versão de Q cujo timestamp de escrita é o mais alto timestamp, menor ou igual a TS(T i ). Se a transação T i emitir um read(q), então o valor recebido será o conteúdo da versão Q k. Se a transação T i emitir um write(q) e Ts(T i ) < R-timestamp(Q k ), então a transação T i será desfeita. De outro modo, se TS(T i ) = W-timestamp(Q k ) o conteúdo de Q k é sobreposto; caso contrário, outra versão de Q é criada.
Esquema: As versões que não forem mais necessárias serão removidas conforme a regra seguinte: Suponha que haja duas versões, Q k e Q j de um item k j de dados Q e que ambas as versões tenham o W- timestamp menor que o timestamp da última transação do sistema. Então, a mais antiga entre as versões Q k e Q j não será usada novamente e pode ser eliminada.
Vantagens e Desvantagens Vantagem: Garante que uma solicitação de leitura nunca falhe e nunca espere. Desvantagem: A leitura de um item de dados exige também a atualização do campo R-timestamp, resultando em dois acessos ao disco ao invés de apenas um. Os conflitos entre as transações são resolvidos por rollback, em vez da imposição do tempo de espera.
Multiversão com Bloqueio em Duas Fases Tenta combinar as vantagens do controle de concorrência multiversão com as vantagens do bloqueio em duas fases. Neste esquema: As transações de atualização executam um bloqueio em duas fases rigoroso (mantêm todos os bloqueios até o final da transação). Cada item de dado possui um único timestamp, baseado em um contador, chamado ts-counter, o qual é incrementado durante o processo.
Esquema: Marca-se os timestamps das transações somente de leitura por meio do valor corrente do contador (lendo o valor de ts-counter antes de começar a execução). Para leitura, esse esquema segue o protocolo de multiversão ordenada por timestamp. Quando uma transação T i (somente leitura) emite um read(q), o valor recebido é o conteúdo da versão cujo timestamp é o inferior a TS(T i ) mais próximo. Quando uma transação de atualização lê um item de dados, ela impõe um bloqueio compartilhado ao item, e lê a sua última versão. Quando uma transação de atualização deseja escrever um item de dados, ela primeiro consegue o bloqueio exclusivo sobre esse item, e então, cria uma nova versão do item de dado. A escrita é realizada a partir da nova versão e o timestamp da nova versão recebe como valor inicial, que é maior que qualquer outro timestamp possível.
Esquema: Quando uma transação de atualização T i completa suas ações, ela realiza o processo de efetivação da seguinte forma: T i adiciona 1 ao valor de ts-counter e transfere esse valor aos timestamps de todas as versões que criou; Ti adiciona 1 ao valor de ts-counter. Somente uma transação de atualização por vez pode realizar o processo de efetivação. Como conseqüência, as transações somente de leitura que começarem depois de T i incrementar o ts-counter acessarão o valor atualizado por T i, enquanto aquelas que começarem antes do incremento de ts_counter, feito por T i, verão o valor anterior à atualização de T i. Neste caso, as transações somente de leitura jamais precisarão esperar por bloqueios. As versões são eliminadas de modo similar ao esquema de multiversão com ordenação por timestamp.
Manuseio de Deadlock Um sistema está em estado de deadlock se há um conjunto de transações, tal que toda transação deste conjunto está esperando outra transação também contida nele. Seja o conjunto {T 0, T 1,..., T n }. T 0 está esperando um item de dados mantido por T 1, T 1 está esperando por um item de dados mantido por T 2,..., T n-1 está esperando um item de dado mantido por T n e T n está esperando um item de dados mantido por T 0. Existem dois métodos principais para tratamento de deadlock: Prevenção de deadlock: garante que o sistema nunca entrará em tal situação. Mais utilizado quando há alta probabilidade do sistema entrar em deadlock. Detecção e recuperação de deadlock: permite que o sistema entre em um estado de deadlock, para então recuperá-lo.
Prevenção Abordagem 1: Obriga que cada transação bloqueie todos os itens de dados antes de sua execução. Ou todos os itens de dados são bloqueados de uma vez ou nenhum o será. Desvantagens: Dificuldade em prever, antes da transação começar, quais itens de dados precisarão ser bloqueados (seria necessário o uso de um esquema de informação nas transações); A concorrência é bastante reduzida.
Prevenção Abordagem 2: Caracterizada pela preempção e rollback de transações. Na preempção, quando uma transação T 2 solicita um bloqueio que está sendo mantido pela transação T 1, o bloqueio concedido a T 1 pode ser revisto por meio do roolback de T 1, e concedido a T 2. Para controlar esta preempção, considera-se um único timestamp para cada transação. Eles são usados para decidir se a transação pode esperar ou será revertida. O bloqueio continua sendo usado para controlar o concorrência. Se uma transação for revertida, ela manterá seu timestamp antigo quando for reiniciada.
Esquemas Esperar-morrer (wait-die): Tem por base uma técnica de não-preempção. Quando uma transação T i solicita um item de dados mantido por T j, T i pode esperar somente se possuir um timestamp menor do que T j (isto é, T i é mais antiga que T j ). Caso contrário, T i será revertida (morta). Por exemplo, suponha que as transações T 2, T 3 e T 4 tenham timestamps 5, 10 e 15, respectivamente. Se T 4 solicita um item de dados mantido por T 3, então, T 4 será desfeita.
Esquemas Ferir-esperar (wound-wait): Tem por base a técnica da preempção e é uma contrapartida ao esquema esperar-morrer. Quando uma transação T i solicita um item de dado mantido por T j, T i poderá esperar somente se possuir um timestamp maior que T j (ou seja, T i é mais nova que T j ). Caso contrário, T j será desfeita (T j é ferida por T i ). Retornando ao exemplo anterior. Se T 2 solicita um item de dados mantido por T 3, então o item de dados será liberado de T 3, e T 3 será desfeita. Se T 4 solicitar um item de dados mantido por T 3, então T 4 esperará.
Prevenção Ambos os esquemas da segunda abordagem evitam inanição. Diferenças entre os dois esquemas da segunda abordagem: No esquema esperar-morrer, a transação mais antiga precisará esperar até que a mais nova libere seus itens de dados. Assim, quanto mais antiga a transação, maior a possibilidade de esperar. Em contraste, no esquema ferir-esperar, a transação mais antiga nunca espera a mais nova. No esquema esperar-morrer, se uma transação T i morre e é desfeita porque solicitou um item de dados bloqueado por uma transação T j, então T i pode reemitir a mesma seqüência de solicitações quando for reiniciada. Se os itens de dados ainda estiverem bloqueados por T j, então T i morrerá novamente. Assim, T i poderá morrer diversas vezes antes de conseguir o item de dados necessário. No esquema feriresperar, a transação T i será ferida e revertida porque T j solicitou um item de dados bloqueado por ela. Quando T i reinicia e solicita o item de dados bloqueado por T j, T i esperará. Com isso, deve haver menos reversões.
Timeout Uma transação que tenha solicitado um bloqueio espera por ele por um determinado período de tempo. Se o bloqueio não for conseguido dentro desse intervalo, é dito que o tempo da transação está esgotado. Assim ela mesma se reverte e se reinicia. Se de fato estiver ocorrendo um deadlock, uma ou mais transações nele envolvidas terão seu(s) tempo(s) esgotado(s) e se reverterá/reverterão, permitindo a continuação de outras. É fácil de ser implementado, trabalha bem se as transações forem curtas, e se longa esperas forem freqüentes em função de deadlocks. É difícil mensurar o tempo de espera. Não está livre da presença de inanição.
Detecção de Deadlock e Recuperação Um mecanismo que examina o estado do sistema é acionado periodicamente para determinar se um deadlock está ocorrendo. Se estiver, então precisa tentar recuperá-lo. Para isso ele precisa: Manter informações sobre alocação corrente dos itens de dados para transações, assim como qualquer solicitação de itens de dados pendentes; Proporcionar um algoritmo que use essas informações para determinar se o sistema entrou em estado de deadlock; Recuperar-se de um deadlock quando o algoritmo de detecção determinar que ele ocorreu.
Detecção Seja o grafo G = (V,E), em que V é um conjunto de vértices e E um conjunto de arestas. O conjunto de vértices consiste em todas as transações do sistema. Cada elemento do conjunto E de arestas é um par ordenado T i T j. Se T i T k está em E, então isto implica que a transação T i está esperando que a transação T k libere o item de dado que ela precisa. A inserção e remoção de arestas no grafo são feitas de acordo com a solicitação de um item bloqueado ou da liberação de um item bloqueado. Há deadlock no sistema se, e somente se, o grafo contiver um ciclo. Cada transação envolvida no ciclo está envolvida no deadlock.
Exemplo: A transação T 1 está esperando as transações T 2 e T 3. A transação T 3 está esperando a transação T 2. A transação T 2 está esperando a transação T 4. T2 T4 T1 T3
Exemplo: Suponha agora que T 4 esteja solicitando um item bloqueado por T 3. T2 T4 T1 T3
Detecção Quando evocar o algoritmo de detecção? Depende da freqüência de ocorrência de deadlocks. Depende de quantas transações serão afetadas por um deadlock. Se os deadlocks ocorrem com freqüência, então o algoritmo será evocado com mais freqüência. Na pior das hipóteses, a chamada ao algoritmo de detecção se dará sempre que uma solicitação de alocação não puder ser imediatamente atendida.
Recuperação Reverter uma ou mais transações para quebrar o deadlock. Devem ser tomadas três ações: Selecionar uma vítima (ou vítimas) de acordo como mínimo custo: A quanto tempo a transação está em processamento e quanto tempo será ainda necessário para que a tarefa seja completada; Quantos itens de dados a transação usou; Quantos itens ainda a transação usará até que se complete; Quantas transações serão envolvidas no rollback. Rollback: Determinar até que ponto a transação deve ser revertida: Reverter totalmente; O suficiente para quebrar o deadlock (exige informações adicionais). Inanição: Deve-se garantir que uma transação seja escolhida vítima somente um número finito e pequeno de vezes.
Operações de Inserção e Remoção Operações adicionais: delete(q): remove o item de dado Q do banco de dados; insert(q): insere um novo item de dado Q em um banco de dados e lhe designa um valor inicial. Uma transação T i que queira operar um read(q) depois da remoção de Q resulta em erro lógico em T i. Um transação T i que pretenda realizar uma operação de read(q) antes da inserção de Q, também resultará em um erro lógico em Ti. Também será um erro lógico tentar remover um item de dado inexistente.
Remoção Quando uma operação de remoção entra em conflito com outras? Se uma transação quiser ler o item que a outra removeu; Se uma transação quiser escrever o que a outra removeu; Se uma transação quiser remover o que a outra removeu; Se uma transação quer remover e outra inserir: a remoção só pode ser feita se a inserção já ocorreu ou se o dado já existia e, a inserção só deve ocorrer se o dado não existe. Se o bloqueio em duas fases for usado, é preciso um bloqueio exclusivo sobre o item de dados antes que ele possa ser removido. Para o protocolo timestamp é preciso um controle similar ao usado para o write.
Inserção A inserção entra em conflito com a remoção, como já visto. Nenhum read ou write pode ser realizado sobre um item de dados antes que ele exista. A inserção é tratada de modo similar à operação write.
Fontes Bibliográficas: Sistemas de Banco de Dados (Cap. 16). Abraham Silberchatz, Henry F. Korth, S Sudarshan. 5ª Ed. Elsevier, 2006. Sistemas de Banco de Dados (Cap. 18). Ramez Elmasri e Sham Navathe. 4ª Ed. Pearson, 2005. Leitura Complementar: Controle de Concorrência e Distribuição de Dados: A teoria clássica, suas limitações e extensões modernas. João Eduardo Ferreira e Marcelo Finger. São Paulo: Escola Brasileira de Computação, 2001.