...

Transações ± finalizando
Galina Resumo baseado no livro do Silberschatz Capítulo: transações

Roteiro
‡ ‡ ‡ ‡ ‡ ‡ Conceito Propriedades ACID Estados da transação Implementação de Atomicidade e Durabilidade Execuções concorrentes Serialização ± Serialização de conflito ‡ Recuperação ± Escalas de execução recuperáveis ± Escalas sem cascata ‡ Implementação do isolamento

Recuperação
‡ Até o momento ± Quais escalas são aceitáveis do pto de vista da consistência do banco
‡ Supondo que não ocorram falhas de transação
± Mas e se ocorrerem falhas de transação durante a execução concorrente?? » Se uma transação Ti falhar, precisamos desfazer seus efeitos para garantir a propriedade de atomicidade da transação » Em um sistema que permite execução concorrente, também é necessário assegurar que qquer transação Tj que seja dependente de Ti (isto é, Tj leu dados escritos por Ti) tbém seja abortada » Para isso: colocar restrições no tipo de escalas permitidas (quais escalas de execução são aceitáveis)

Escalas de execução recuperáveis
‡ Considere:
T8 Read (A) Write (A) Read(A) Read(B) T9

‡ Suponha que o sistema permita que T9 seja efetivada imediatamente após executar read(A)
± T9 é efetivada antes que T8 o seja

‡ Suponha que T8 falhe antes da efetivação
± Como T9 leu o valor do item A escrito por T8, temos que abortar T9
‡ Mas T9 já foi efetivada e não pode ser abortada
± Impossível se recuperar corretamente da falha de T8

Escalas de execução recuperáveis (2)
‡ Este é um exemplo de escala não recuperável
± NÃO deve ser permitida

‡ Maioria dos SGBDs exige que todas as escalas sejam recuperáveis
± Uma escala recuperável é aquela na qual, para cada par de transações Ti e Tj, tal que Tj leia itens de dados previamente escritos por Ti, a operação de efetivação de Ti apareça antes da operação de efetivação de Tj

Escalas sem cascata ‡ Para o sistema recuperar-se corretamente de uma falha em Ti ± Pode ser necessário desfazer várias transações ‡ Ex: se tais transações leram dados escritos por Ti ‡ Ex: Se T10 falha após o read(A) de T12 retorno em cascata: Desfazer T11 e T12 T10 Read(A) Read(A) Write(A) T11 T12 read(A) write(A) read(A) .

Escalas sem cascata (2) ‡ Retorno em cascata é indesejável ± Desfaz muito trabalho ‡ Conveniente restringir as escalas àquelas nas quais os retornos em cascata não possam acontecer ± Chamadas de escalas sem cascatas ‡ Uma escala sem cascata é aquela na qual para cada par de transações Ti e Tj. tal que Tj leia um item de dados previamente escrito por Ti. a operação de efetivação de Ti apareça antes da operação de leitura de Tj ‡ Toda escala sem cascata tbém é recuperável .

mantenha-se escalas aceitáveis ‡ Exemplo simples: ± Bloquear o banco de dados e libera após a efetivação » Um bloqueio por vez ->Escalas seqüenciais! » Proporciona desempenho pobre e baixo grau de concorrência .Implementação do isolamento ‡ Até agora ± Como manter a consistência do banco ‡ Escalas conflito serializáveis e sem cascata ‡ Esquemas de controle de concorrência ± Garante que mesmo para várias transações concorrentes.

Teste de serialização ‡ Ao projetar esquemas de controle de concorrência ± Deve-se mostrar que as escalas geradas são serializáveis ‡ Como determinar se uma escala S é serializável? ± Teste de serialização de conflito .

então podemos alternar as instruções sem afetar os resultados. pois o valor final gerado depende de quem executar por último ( e isso afeta quem for ler o valor depois) . escreve depois ou escreve antes e lê depois ‡ write(q). read(q): seqüência de execução importa: lê antes.‡ Considerar instruções sucessivas de transações diferentes. então a ordem pode importar! ‡ Quatro casos a considerar: ‡ read(q). ‡ Idéia geral: se as instruções referem-se a itens de dados diferentes. write(q): seqüência de execução importa: lê antes. write(q): importa. read(q): seqüência de execução não importa. escreve depois ou escreve antes e lê depois ‡ write(q). se as instruções referem-se ao mesmo item de dados. pois o mesmo valor é lido ‡ read(q).

para as quais uma das condições se verifica » Ti executa write(q) antes de Tj executar read(q) » Ti executa read(q) antes de Tj executar write(q) » Ti executa write(q) antes de Tj executar write(q) ‡ Se há uma aresta Ti -> Tj no grafo. então ± Em qquer escala sequencial S¶ equivalente a S » Ti deve aparecer antes de Tj .Teste de serialização de conflito ‡ Seja uma escala S ‡ Construir um grafo ± Grafo de precedência de S ‡ Vértices ± Transações que participam da escala ‡ Arestas ± Ti -> Tj.

Exemplo ± para a escala 1. tem-se o seguinte grafo de precedência Todas as instruções de T1 são executadas antes de T2 .

Grafo de precedência para a escala 4 Aresta T1->T2 Pq T1 executa read(A) antes de T2 executar write(A) Aresta T2->T1 Pq T2 executa read(B) antes de T1 executar write(B) .

para testar a serialização de conflito ± Construir o grafo de precedência ± Chamar um algoritmo de detecção de ciclos .Grafos de precedência ‡ Se o grafo de precedência para S tem um ciclo ± Então a escala S não é conflito serializável ‡ Caso contrário (sem ciclos) ± A escala S é serializável ‡ Logo.

Verificando os exemplos anteriores ‡ Escala 1 ± Sem ciclos ‡ Escala 2 ± Sem ciclos ‡ Escala 4 ± inconsistente ± Com ciclos .

Verificando os exemplos anteriores ‡ Escala 3 consistente ± Sem ciclos .

Concorrência ‡ Propriedade fundamental da transação ± Isolamento ‡ Diversas transações concorrentes ± Isolamento pode não ser preservado ‡ Responsabilidade do sistema controlar a interação entre transações concorrentes ± Através de mecanismos chamados de esquemas de controle de concorrência ‡ Base destes mecanismos ± Propriedade da serialização! .

Protocolos com base em bloqueios (lock) ‡ Obrigar que o acesso aos itens de dados seja feito de maneira mutuamente exclusiva ± Enqto uma transação acessa um item de dados ‡ Nenhuma outra transação pode modificá-lo ± permitir o acesso a um item de dados somente se ele estiver bloqueado ‡ Bloqueios ‡ Concessão de bloqueios ‡ Protocolo de bloqueio em duas fases .

Bloqueios ‡ Tipos de bloqueios ± bloqueio compartilhado (S) ‡ T pode ler mas não pode escrever 1 dado q ± bloqueio exclusivo (X) ‡ T pode ler e escrever 1 dado q ‡ Cada transação solicita o bloqueio do dado q de modo apropriado ± dependendo do tipo de operação realizada em q ‡ A solicitação é direcionada para o gerenciador de controle de concorrência ‡ A transação pode realizar suas operações somente depois que o gerenciador de controle de concorrência conceder o bloqueio para a transação .

‡ No final de uma transacção todos os objetos bloqueados pelas instruções dessa transacção são libertados. . todos os registos (tabelas) alterados são automaticamente bloqueados de modo a impedir que outras transacções os possam alterar simultaneamente.Bloqueio Idéia Básica ‡ Durante uma transacção. ‡ Se uma transacção tentar alterar um objecto reviamente bloqueado por outra transacção ficará suspensa em lista de espera até que esse objecto seja libertado.

.

tabelas através de instruções CREATE TABLE.g. ALTER TABLE.DROP TABLE). ± o SGBD bloqueia implicitamente as tabelas/registos que estão a ser alterados por um utilizador. . ± um utilizador pode adquirir explicitamente um bloqueio numa tabela da base de dados.‡ Bloqueio do dicionário de dados: ± permite controlar o acesso à definição de objectos na base de dados (e. ± é controlado automaticamente pelo SGBD. ‡ Bloqueio de manipulação de dados: ± permite controlar o acesso aos dados nas tabelas.

‡ Bloqueio de registo .aplica-se a toda a tabela.Níveis de Bloqueios ‡ Bloqueio de tabela .aplica-se apenas a um registo de uma dada tabela .

Tipos de Bloqueios (Oracle) .

Operações Implícitas .

Bloqueios Implícitos .

Bloqueios (2) ‡ Matriz de compatibilidade de bloqueios lock-S(q) ‡ Para ter acesso a um dado lock-X(q) ± a transação precisa primeiro bloqueá-lo unlock(q) ‡ Se o dado já estiver incompativelmente bloqueado por outra transação ± o gerenciador de controle de concorrência não concederá o bloqueio até que todos os bloqueios incompatíveis mantidos pela outra transação sejam desfeitos .

Bloqueios (3) ‡ Uma transação pode desbloquear um dado a qualquer momento ± uma transação precisa manter o bloqueio do dado durante todo o tempo de acesso àquele item ‡ No entanto ± o desbloqueio imediatamente após o acesso final nem sempre é interessante. Exemplo: ‡ T1 transfere 50 reais de B para A ‡ T2 apresenta o saldo total das contas A e B .

Bloqueios (4) ‡ T1: Lock-x(B) read(B). A=A+50.. Write(A). Unlock (A) ‡ T2: ‡ Sejam saldos A= 100 e Lock-s(A) B=200 read(A).. a escala a unlock (B) seguir pode ocorrer. B=B-50 Write(B) Unlock (B) Lock-x(A) Read(A). ‡ Se forem executadas unlock (A) seqüencialmente: A + B = 300 Lock-s(B) ‡ Se forem executadas Read(B) concorrentemente.: display (A+B) .

Bloqueios (5) Neste caso: T2 vai mostrar 250 Incorreto! Erro provém da falta de bloqueio em tempo hábil do item B .

Unlock (B) Unlock (A) T4: (similar a T2. A=A+50. Lock-s(B) Read(B) display (A+B) unlock (A) unlock (B) Agora não se tem o erro anterior . Write(A). mas com desbloqueio no final da transação) Lock-s(A) read(A). B=B-50 Write(B) Lock-x(A) Read(A).Bloqueios (5) ‡ Suponha agora que os desbloqueios sejam realizados ao final da transação: T3: (similar a T1. mas com desbloqueio no final da transação) Lock-x(B) read(B).

liberar os itens que estavam bloqueados . e por conseqüência.Bloqueios (6) ‡ Infelizmente ± Bloqueios podem causar situações indesejáveis ‡ Ex: escala parcial de T3 e T4 ± T4 espera que T3 libere B ± T3 espera que T4 libere A ‡ deadlock! ± O sistema precisa desfazer uma das duas transações: tratados através de rollbacks » Desfazer uma das transações.

tão necessários para evitar inconsistência ± Deadlocks podem ser preferíveis a estados inconsistentes » Podem ser tratados por rollback! .Bloqueios (7) ‡ Logo ± Se usarmos bloqueio ou desbloqueio tão logo seja possível ‡ Poderemos chegar a resultados inconsistentes ± Por outro lado ‡ Se não desbloquearmos um dado antes de solicitarmos um bloqueio a outro dado ± Poderá ocorrer deadlock » Formas de evitar deadlock ± Mas deadlock é inerente aos bloqueios.

Concessão de bloqueios ‡ Cada transação deve seguir um conjunto de regras ± Protocolo de bloqueio ‡ Indica quando uma transação pode ou não bloquear ou desbloquear cada dado ‡ Restringe o número de escalas de execução possíveis ‡ Concessão de bloqueios ± Quando uma transação solicita bloqueio sobre um determinado item de dado ‡ e nenhuma outra transação mantém o mesmo item de dado bloqueado de modo conflitante ± tal bloqueio pode ser concedido .

mas T1 tem que esperar. pois T3 está executando ± Mas.Concessão de bloqueios (2) ‡ Evitar a seguinte situação ± T2 tem bloqueio compartilhado sobre um dado ± T1 solicita bloqueio exclusivo sobre este dado ‡ Logo: T1 espera T2 desbloquear ± Mas. enquanto isso ‡ T4. enquanto isso ‡ T3 solicita bloqueio compartilhado sobre o dado e é concedido (leitura-leitura) ± Nessa altura ‡ T2 libera o bloqueio. ‡ T1 nunca consegue bloqueio exclusivo! ± T1 é chamada de starved ‡ inanição de transações ...

Concessão de bloqueios (3) ‡ Para evitar inanição: ± Quando uma transação Ti solicita bloqueio do dado q de um modo particular M. o bloqueio só é concedido se: ‡ 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 ‡ Ou: ± Aumenta a prioridade da transação à medida que aumenta o tempo de espera da transação .

Protocolo de Bloqueio em duas fases ‡ Garante a serialização ‡ Exige que cada transação emita suas solicitações de bloqueio e desbloqueio em duas fases: ± fase de expansão ‡ 1 transação pode obter bloqueios. mas não pode liberar nenhum ± fase de encolhimento ‡ 1 transação pode liberar bloqueios. mas não consegue obter nenhum bloqueio novo .

uma transação está em fase de expansão ± adquire os bloqueios de que precisa ‡ Tão logo a transação libera um bloqueio ± ela entra em fase de encolhimento e não poderá solicitar novos bloqueios ‡ As instruções de desbloqueio não precisam aparecer no final da transação. unlock(B) poderia ver logo após lock-X(A) . necessariamente! ± Exemplo: Em T3.Protocolo de Bloqueio em duas fases (2) ‡ Inicialmente.

.Protocolo de Bloqueio em duas fases (3) ‡ O protocolo de bloqueio em duas fases garante a serialização de conflitos ‡ Mas não garante a ausência de deadlock (T3 e T4!) ‡ Além de serem serializadas ± É desejável que as escalas de execução não sejam em cascata ‡ Rollback em cascata pode ocorrer com o protocolo de bloqueio em duas fases..(próximo slide) ..

Protocolo de Bloqueio em duas fases (4) ‡ Exemplo: ± Cada transação segue o protocolo de bloqueio em duas fases ‡ Mas a falha de T5 depois do read(A) da transação T7 ocasiona o rollback em cascata de T6 e T7 ‡ Rollbacks em cascata podem ser evitados ± Bloqueio em duas fases severo (strict) .

Protocolo de Bloqueio em duas fases (5) ‡ Bloqueio em duas fases severo (strict) ± Tbém: bloqueio feito em duas fases ± Além: todos os bloqueios de modo exclusivo tomados por uma transação sejam mantidos até que a transação seja efetivada ‡ Garante que qquer dado escrito por uma transação que ainda não foi efetivada mantenha-se bloqueado de modo exclusivo até que a transação seja efetivada ± Evitando que qquer outra transação leia o dado em transição ‡ Tbém não garante a ausência de deadlock .

Protocolo de Bloqueio em duas fases (6) ‡ Outra variante do bloqueio em duas fases: ± Bloqueio em duas fases rigoroso (Rigorous) ‡ Tbém: bloqueio feito em duas fases ‡ Além: todos os bloqueios (exclusivos e compartilhados) sejam mantidos até que a transação seja efetivada ‡ Outra variante do bloqueio em duas fases: ± Bloqueio em duas fases conservativo (conservative) ‡ Tbém: bloqueio feito em duas fases ‡ Além: todos os bloqueios são feitos antes do início da transação ‡ Evita deadlocks Maioria dos SGBDs implementa o bloqueio em duas fases severo ou o rigoroso ‡ .

T8 pode bloquear a1 no modo compartilhado e depois mudar para o modo exclusivo ± Mais concorrência!... . Read(an) Write(a1) ± T9 Read(a1) Read(a2) Display(a1+a2) ‡ Se empregarmos o bloqueio em duas fases ± T8 precisará bloquear a1 de modo exclusivo ‡ Qquer execução concorrente de ambas transações atinge uma execução serial ‡ Note que T8 precisa de um bloqueio exclusivo de a1 somente ao fim da execução ± Qdo escreve a1 ‡ Assim...Protocolo de Bloqueio em duas fases (7) ‡ Considere: ± T8 Read(a1) Read(a2) ..

Protocolo de Bloqueio em duas fases (8) ‡ Refinamento do bloqueio em duas fases ± Permite a conversão de bloqueios ‡ De compartilhado para exclusivo: promoção (upgrade) ‡ De exclusivo para compartilhado: rebaixamento (downgrade) Conversão não pode ser arbitrária ± Promoção só pode acontecer na fase de expansão ± Rebaixamento só pode acontecer na fase de encolhimento Exemplo: Note que: ± Uma transação tentando a promoção de um bloqueio do item q pode ser forçada a esperar ‡ Se Q estiver bloqueado por outra transação em modo compartilhado ‡ ‡ .

seguida de uma instrução write(q) ± Se nã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 de a transação ser efetivada ou abortada .Protocolo de Bloqueio em duas fases (9) ‡ Como gerar instruções de bloqueio e desbloqueio automaticamente para uma transação? ± Qdo Ti emite uma operação read(q) ‡ Sistema emite uma instrução lock-S(q) seguida de uma instrução read(q) ± Qdo Ti emite uma operação write(q) ‡ Sistema verifica se Ti ainda mantém um bloqueio compartilhado ± Se sim: sistema emite uma instrução upgrade(q).

com conversão de bloqueios. são usados extensivamente! ‡ Outros tipos de bloqueios .Em SGBDs comerciais ‡ Bloqueio em duas fases severo e rigoroso.

Manuseio de deadlock ‡ Um sistema está em estado de deadlock se há um conjunto de transações. tal que toda transação desse conjunto está esperando outra transação também contida nele ‡ Ex: ± T0 está esperando um dado mantido por T1 ± T1 está esperando um dado mantido por T2 ± T2 está esperando um dado mantido por T0 ‡ Nenhuma das transações pode prosseguir! ‡ Reverter uma das transações envolvidas no deadlock: rollback .

caso contrário. a detecção e recuperação são mais eficientes ± Veremos! .Manuseio de deadlock (2) ‡ Dois métodos principais para o tratamento de deadlock: ± prevenção de deadlocks ‡ garantir que o sistema não entre em tal situação ± remover o sistema do estado de deadlock ‡ detecção de deadlock e recuperação de deadlock ‡ Ambos os métodos podem acabar por reverter uma transação (rollback) ‡ A prevenção é mais utilizada se a probabilidade de o sistema entrar em deadlock for relativamente alta.

Dead Lock.Impasse .

± Pode deixar transacções à espera durante periodos muito longos. todos os recursos que se pretende vir a alterar: ± Afecta a utilização partilhada dos recursos. no início da transacção.Prevenir Impasses ‡ Bloquear explicitamente. ‡ Impor uma ordem para o bloqueio dos recursos e garantir que todas as transações seguem essa ordem ± Pode ser de difícil concretização para certas aplicações .

Detectar Impasses ‡ Grafo de esperas (wait-for graph) ± O SGBD mantém um grafo dirigido que representa as transações que estão à espera que recursos bloqueados por outras transacções sejam libertados. ‡ Este grafo é analisado periodicamente pelo sistema para detectar situações de impasse. .

Grafo de Espera .

± Se o recurso foi libertado porque a transacção que o bloqueava fez rollback to savepoint. se necessário: ± Se o recurso foi libertado porque a transacção que o bloqueava terminou. então o nó correspondente a essa transacção é eliminado e com ele todos os arcos que chegavam a esse nó. se isso implicar o fim da espera de uma transacção. ± Sempre que um recurso é libertado o grafo é actualizado. . ± Sempre que uma transacção fica à espera que um recurso seja libertado por outra transacção o sistema acrescenta um arco entre os nós em causa. então. o arco correspondente é retirado do grafo.Manutenção Grafo de Espera ‡ O SGBD vai mantendo actualizado o estado do grafo: ± Sempre que uma transacção é iniciada o sistema acrescenta um novo nó ao grafo.

± Monte a transação T1. será descontado da conta A.5% da conta A do valor que está sendo transferido. sem levar em conta operações de lock e unlock.50 relativos à taxa. Monte uma transação que faça esta operação. Alem da transferência propriamente dita. . deve ser descontada uma taxa de 0.Exercícios 1) Considere a transação T1 que transfere 100 reais de uma conta A para uma conta B. Por exemplo. além dos 100 reais. também R$ 0.

read(B). if A=0 then B=B+1. read(A). Seja um requisito de consistência A=0 ou B=0. write (B). com valores iniciais A=B=0. ± Mostre que toda execução seqüencial que envolve T1 e T2 preserva a consistência dos dados. write (A). T2: read(B). ± Mostre uma execução concorrente de T1 e T2 que produza uma escala não serializável . if B=0 then A=A+1.Exercícios (2) 2) Considere T1 e T2: T1: read(A).

Adicione instruções de bloqueio e desbloqueios às transações T1 e T2 de modo que observem o protocolo de bloqueio em duas fases. write (A). if A=0 then B=B+1. if B=0 then A=A+1. write (B). read(B). read(A). A execução dessas transações pode resultar em deadlock? Justifique. T2: read(B).Exercícios (3) 3) Considere T1 e T2: T1: read(A). .

Sign up to vote on this title
UsefulNot useful