Transações e Concorrência

(1)

Transações e Concorrência

Daniela Barreiro Claro MATA-60

(2)

 Transação: programa em execução que forma

uma unidade lógica de processamento que consiste de uma ou mais operações

 Acessa dados através de duas operações: READ(Q) e

WRITE(Q)

 Exemplo: uma transferência de dinheiro entre duas

contas executa uma transação consistente em duas atualizações, uma para cada conta

(3)

 É fundamental que todas as ações da transação

sejam executadas completamente

 Caso contrário, os efeitos parciais devem ser desfeitos

 A transação inteira é executada ou nenhuma

parte dela é executada

(4)

 Para garantir a integridade dos dados, é

necessário que o sistema de banco de dados mantenha as seguintes propriedades das

transações:  Atomicidade  Consistência  Isolamento Durabilidade

Propriedades ACID

(5)

 Atomicidade: todas as operações da transação

são persistidas no banco de dados, ou nenhuma delas

 Consistência: a execução de uma transação

mantém a consistência do banco de dados após sua execução

(6)

 Isolamento: mesmo várias transações

executando simultaneamente, o sistema garante que uma transação não interfere em outras. Cada transação é isolada.

 Durabilidade: depois que uma transação é

completada com sucesso, as mudanças devem ser persistidas no banco de dados, não podendo

(7)

 Exemplo: transação bancária de 50 reais da conta

A para a conta B, as operações seriam (T_i):

 read(A);  A = A - 50;  write(A);  read(B);  B = B + 50;  write(B);

Propriedades ACID

(8)

Propriedades ACID

Atomicidade

Suponha que antes de executar a transação Ti os valores de A e B são R$ 100 e R$ 500, respectivamente. Durante a execução de Ti acontece uma falha (energia, hardware ou software) que impede Ti de completar com sucesso. A falha acontece após a operação write(A), mas antes da operação write(B). O que vai ocorrer?

(9)

Propriedades ACID

Consistência

O requisito de consistência é que a soma de A e B sejam inalterados pela execução da transação. Qual o exemplo que poderia causa inconsistência nos dados?

- programador de aplicação

(10)

Propriedades ACID

Isolamento

Considere que a transação Tj esteja efetuando um saque de R$ 100 na conta A simultaneamente a transação Ti e as contas não podem ficar com saldo negativo (Conta Poupança). Caso Ti inicie antes de Tj e após read(A), mas antes de write(A), a transação Tj seja completada com sucesso, o que vai ocorrer?

(11)

Propriedades ACID

Durabilidade

O sistema deve garantir que os dados, mesmo após uma falha, sejam persistidos no disco. No nosso exemplo, se o usuário for notificado que a transação foi realizada com sucesso, os dados devem ser armazenados no disco, garantindo que em caso de falha no sistema

(principalmente por falta de energia) os dados não sejam perdidos.

(12)

Estado da transação

Ativa Parcialmente confirmada Falha Abortada Confirmada Enquanto estiver executando rollback commit Encerrada

(13)

 Quando ocorre uma falha na transação, ela é

considerada abortada

 Quando há mudanças causadas por uma

transação abortada tiverem sido desfeitas, dizemos que a transação foi revertida

 Uma transação que completa sua execução com

sucesso é considerada confirmada

Transação confirmada só é desfeita por uma outra transação de compensação.

Estado da transação

(14)

 É muito mais fácil executar transações

serialmente, ou seja, uma de cada vez

 Vantagens da execução concorrente:

 Aumento do número de transações executadas

 Melhor uso dos recursos computacionais

 Tempo de espera reduzido

 É preciso garantir a execução simultânea correta

(15)

 Representam a ordem cronológica em que as

instruções são executadas

 Devem preservar a ordem em que as instruções

aparecem em cada transação individual

 O schedule S de n transações T₁, T₂, ..., T_n

 As operações em S devem ocorrer na mesma ordem

que em T_i

(16)

 Um plano S com n transações é serializável se

ele for equivalente a um plano serial

 Um plano não-serializável não se garante que o

mesmo seja correto

 Exemplo: Transferência bancária entre duas contas, conta

A com R$ 1000,00 e conta B com R$ 2000,00.

 Transação 1: A transfere R$ 50,00 para B

 Transação 2: A transfere 10% do valor da conta para B

(17)

Planos seriais (sequenciais)

T1 T2 read(A) A = A - 50 write(A) read(B) B = B + 50 write(B) read(A) temp = A * 0.1 A = A - temp write(A) read(B) B = B + temp write(B) A = 1000 A = 1000 - 50 A = 950 B = 2000 B = 2000 + 50 B = 2050 A = 950 temp = 950 * 0.1 A = 950 - 95 A = 855 B = 2050 B = 2050 + 95 B = 2145 T3 T4 read(A) A = A - 50 write(A) read(B) B = B + 50 write(B) read(A) temp = A * 0.1 A = A - temp write(A) read(B) B = B + temp write(B) A = 900 A = 900 - 50 A = 850 B = 2100 B = 2100 + 50 B = 2150 A = 1000 temp = 1000 * 0.1 A = 1000 - 100 A = 900 B = 2000 B = 2000 + 100 B = 2100 A = 1000 B = 2000 Soma = 3000 A = 855 B = 2145 Soma = 3000 A = 850 B = 2150 Soma = 3000

(18)

Planos não seriais

(intercalados) T1 T2 read(A) A = A - 50 write(A) A = 950 temp = 950 * 0.1 A = 950 - 95 A = 855 read(B) B = B + 50 write(B) B = 2050 B = 2050 + 95 A = 1000 A = 1000 - 50 A = 950 read(A) temp = A * 0.1 A = A - temp write(A) B = 2000 B = 2000 + 50 B = 2050 read(B) B = B + temp T3 T4 read(A) A = A - 50 A = 1000 temp = 1000 * 0.1 A = 1000 - 100 A = 900 B = 2000 write(A) read(B) B = B + 50 write(B) B = 2050 + 100 A = 1000 A = 1000 - 50 read(A) temp = A * 0.1 A = A - temp write(A) read(B) A = 900 B = 2000 B = 2000 + 50 B = 2050 B = B + temp A = 1000 B = 2000 Soma = 3000 A = 855 B = 2145 Soma = 3000 A = 900 B = 2150 Soma = 3050

(19)

Serializável ou não?

T1 T2 read(A) A = A - 50 write(A) A = 950 temp = 950 * 0.1 A = 950 - 95 A = 855 read(B) B = B + 50 write(B) B = 2050 B = 2050 + 95 B = 2145 A = 1000 A = 1000 - 50 A = 950 read(A) temp = A * 0.1 A = A - temp write(A) B = 2000 B = 2000 + 50 B = 2050 read(B) B = B + temp write(B) T3 T4 read(A) A = A - 50 A = 1000 temp = 1000 * 0.1 A = 1000 - 100 A = 900 B = 2000 write(A) read(B) B = B + 50 write(B) B = 2050 + 100 B = 2150 A = 1000 A = 1000 - 50 read(A) temp = A * 0.1 A = A - temp write(A) read(B) A = 900 B = 2000 B = 2000 + 50 B = 2050 B = B + temp write(B) A = 1000 B = 2000 Soma = 3000 A = 855 B = 2145 Soma = 3000 A = 900 B = 2150 Soma = 3050

(20)

 Como as transações são programas, é difícil

determinar exatamente que operações são realizadas e como interagem

 Considera-se apenas duas operações:

 read e write

 Com isso, entre as duas operações para um dado

Q, pode haver uma sequência qualquer de outras

(21)

 O isolamento é fundamental para garantir a

consistência do banco de dados

 Essa propriedade pode não ser preservada com várias

execuções simultâneas

 Para garantir essa propriedade, o sistema precisa

controlar as interações por técnicas de controle de concorrência

(22)

 Motivação:

 Melhor throughput e utilização

dos recursos

 Tempo de espera reduzido

(23)

 As técnicas para controle de concorrência servem

para assegurar a serialização de planos de

execução usando PROTOCOLOS (conjunto de regras):

 Protocolos baseado em bloqueio, timestamp, gráficos,

validação, etc

(24)

 Impedir que múltiplas transações acessem os

itens concorrentes (armazena uma variável à T_i)

 SE a transação precisar de um item bloqueado

 ENTÃO é forçada a esperar até que o item seja liberado

 Bloquear

 lock_item(Q) ou lock(Q)

 Desbloquear

(25)

Exemplo - Serial

T1: lock_item(A); read(A); A <- A - 50; write(A); unlock_item(A); lock_item(B); read(B); B <- B + 50; write(B); unlock_item(B); T2: lock_item(A); read(A); unlock_item(A); lock_item(B); read(B); unlock_item(B); display(A+B);

(26)

Exemplo - Concorrente

T1 T2 lock_item(A) read(A) A <- A - 50 write(A) read(B) unlock_item(A) lock_item(B) lock_item(A) read(A) unlock_item(A) lock_item(B) read(B)

gerenciador de controle de concorrência

grant(A,T1)

grant(A,T2)

(27)

Continuação - Concorrente

T1 T2 lock_item(B) read(B) B <- B + 50 write(B) unlock_item(B)

grant(B,T1)

(28)

Exemplo - Concorrente

T1 T2 lock_item(A) read(A) A <- A - 50 write(A) read(B) unlock_item(A) lock_item(B) lock_item(A) read(A) unlock_item(A) lock_item(B) read(B)

grant(A,T1)

grant(A,T2)

(29)

Exemplo - Concorrente

T1 T2 lock_item(B) read(B) B <- B + 50 write(B) unlock_item(B)

grant(B,T1)

(30)

 Compartilhado (leitura)

 Pode apenas ler, mas não escrever

 lock-s(Q) ou read_lock(Q)

 Exclusivo (escrita)

 Pode ler e escrever

 lock-x(Q) ou write_lock(Q)

 Desbloquear

 unlock(Q)

(31)

Exemplo - Serial

T1: lock-x(A); read(A); A <- A - 50; write(A); unlock(A); lock-x(B); read(B); B <- B + 50; write(B); unlock(B); T2: lock-s(A); read(A); unlock(A); lock-s(B); read(B); unlock(B); display(A+B);

(32)

 Bloqueios não garantem a serialização e nem a

prevenção de deadlock

 Deve-se ter um protocolo adicional relacionado ao

posicionamento das operações de bloqueio e desbloqueio

 O mais conhecido é o 2PC: Two Phase Commit

(33)

 Um protocolo que assegura a seriação e consiste em duas

fases:

 Fase de crescimento: uma transação pode obter bloqueios, mas não pode

liberar qualquer bloqueio

 Fase de encolhimento: uma transação pode liberar bloqueios, mas não

pode obter novos bloqueios

 Inicialmente, a transação está em fase de crescimento e

pode obter qualquer bloqueio

 Quando a transação libera um bloqueio, ela entra em fase

de encolhimento e não pode obter mais bloqueios

Bloqueio de duas fases

(34)

Exemplo - Duas fases

T1 T2 lock-s(A) read(A) lock-x(B) unlock(A) read(B) B <- B + A write(B) unlock(B) lock-s(B) read(B) lock-x(A) unlock(B) read(A) A <- A + B write(A) unlock(A)

(35)

 2 fases básico

 Conservador: requer que uma transação bloqueie todos os

itens que ela acessa antes que a transação inicie

 Estrito: não libera nenhum de seus bloqueios exclusivos até

terminar a execução da transação

 Rigoroso: não libera nenhum de seus bloqueios (exclusivo

ou compartilhado) até terminar a execução da transação

 Até agora todos os protocolos causam deadlock, como resolver?

(36)

 Timestamp

 Identificador único criado pelo SGBD

 Podem ser um contador ou data/hora

 Cada item de dados Q é associado 2 valores

 W-Timestamp(Q): maior timestamp que tenha executado um

write(Q) com sucesso - Transação mais nova

 R-Timestamp(Q): maior timestamp que tenha executado um

read(Q) - Transação mais nova.

(37)

 Funcionamento: Ti emitiu um READ(Q)  Se TS(Ti) < W-Timestamp(Q) então

■ Ti precisa ler um valor de Q que já foi modificado por outro.

■ Alguma Tj + nova já teria escrito o valor no item Q antes que Ti tivesse a chance de ter lido Q.

■ Logo, READ(Q) é rejeitada e Ti é revertida

 Se TS(Ti)>W-Timestamp(Q) então

■ READ(Q) é executada

■ R-timestamp(Q) é definido como TS(Ti)

(38)

 Funcionamento: Ti emitiu um WRITE(Q)

 Se TS(Ti) < R-Timestamp(Q) então

■ Alguma Tj + nova já leu o valor do item Q antes que Ti tivesse a chance para escrever Q.

■ Logo, WRITE(Q) é rejeitada e Tié revertida

 Se TS(Ti) < W-Timestamp(Q) então

■ WRITE(Q) é rejeitada e Ti é revertida

■ Alguma Tj + nova já escreveu o valor do item Q antes que Ti tivesse a chance para escrever Q

 Caso contrário,

■

(39)

 Se Ti for revertida, o sistema atribui um novo timestamp e

reinicia.

 Este protocolo garante serialização e deadlock-free

 Mas não garante a estagnação (starvation)

 Uma sequência de transações curtas causa o reinício repetido

da transação longa.

 Pode-se evitar a estagnação garantindo que

 Não haja outra T mantendo um bloqueio sobre Q em um modo

que entra em conflito

 Não existe outra T que esteja esperando um bloqueio sobre Q

e que fez a solicitação de bloqueio antes de Ti

Baseado em Timestamp

(40)

 Baseado em Gráfico

 Baseado em Validação (ou Otimista)  Granularidade Múltipla

 Baseada em bloqueios explícitos e implícitos

 Modo de intenção compartilhado  Modo de intenção exclusivo

(41)

 Considere as duas transações a seguir: T1: T2: read(A); read(B); read(B); read(A); if A = 0 then B <- B + 1; if B = 0 then A <- A + 1; write(B); write(A);

 Considere que o requisito de consistência seja A = 0 v B = 0, sendo A = B = 0 os valores iniciais.

a) Mostre que cada execução serial preserva a consistência. b) Mostre uma execução simultânea não passível de seriação. c) Existe uma execução simultânea passível de seriação?

(42)

Silberschatz, A.; Korth, H. F., Sudarshan, S. Sistema de Bancos de Dados. 5a. Edição, Editora Campus, 2006.

Elmasri, R.; Navathe, S. B. Sistemas de Banco de Dados, 6ed. Pearson Addison Wesley, 2011.