transacoes distribuidas

Transações Distribuídas

Ricardo AnidoMC704

2

Modelo de Transações Distribuídas

• Transações podem acessar dados em vários nós.• Cada nó tem um gerente local de transações, responsável por

– Manter log para recuperação.– Coordenar a execução concorrente das transações

executando no nó.• Cada nó tem um coordenador de transações, responsável por

– Iniciar a execução de transações que são originadas no nó.– Distribuir subtransações para nós apropriados.– Coordenar a terminação de transações originadas no nó, o

que resulta na transação ser validada em todos os nós oudesfeita em todos os nós.

3

Arquitetura

Nó 1

GT1

CT1

Nó 2

GT2

CT2

Nó 3

GT3

CT3

4

Controle de Concorrência

• Protocolos baseados em locks• Protocolos baseados em timestamp

5

Protocolos baseados em locks

• Um lock (bloqueio) é um mecanismo para controlede acessos concorrentes a um mesmo item de dados.

• Dados podem ser bloqueados em dois modos:– Exclusivo (E). Dado pode ser escrito ou lido.– Compartilhado (C). Dado pode ser apenas lido.

• Requisições de locks (lock-E ou lock-C) são feitasao gerente de controle de concorrência. Transaçãofica suspensa até que lock seja concedido.

6

Protocolos baseados em locks (cont.)

• Matriz de compatibilidade de locks:

• Pode ser concedido um lock de um dado a umatransação se o lock solicitado é compatível com locksadquiridos por outras transações para o mesmo dado.

• Se o lock não pode ser concedido, a transação querequer o lock é suspensa até que todos os outroslocks incompatíveis sejam liberados pelas outrastransações.

C EC Verdadeiro FalsoE Falso Falso

7

Protocolos baseados em locks (cont.)

• Exemplo de transação com locks:T1:lock-C(A)read(A)unlock(A);lock-C(B)read(B)unlock(B)display(A+B)

• Locks usados como acima não garantem seriação: seA e B forem atualizados entre as leituras de A e B, asoma mostrada estaria errada.

8

Protocolos baseados em locks (cont.)

• Um protocolo para locks é um conjunto de regrasque todas as transações devem seguir para requisitare devolver locks.

• Os protocolos restringem o conjunto deescalonamentos possíveis.

• Problemas que devem ser contornados:– Deadlock– Não garantia de progresso (starvation, liveleness)

9

Deadlock

• Considere o escalonamento parcial

• Nem T3 nem T4 podem prosseguir. Esta situação échamada de deadlock.

• Para tratar o deadlock é necessário desfazer T3 ou T4(rollback), e liberando os locks adquiridos.

T3 T4lockEx(B)read(B)B = B – 50write(B)

lockCp(A)read(A)lockCp(B)

lockEx(A)

10

Falta de garantia de progresso

• Considere:– Uma transação T espera por um lockEx em um

dado, enquanto uma sequência de outrastransações requerem e adquirem um lockCp para omesmo dado.

– A mesma transação T é desfeita repetidamentedevido a deadlock. T nunca progride.

• Potencial para deadlock existe na maioria dosprotocolos baseados em locks; protocolos devem serprojetados de forma a garantir progresso.

11

Protocolo de lock em duas fases

• Garante escalonamento seriável por conflito.

• Fase 1: Crescimento– Transação pode requisitar novos locks.– Transação não pode liberar locks.

• Fase 2: Encolhimento– Transação pode liberar locks.– Transação não pode requisitar novos locks.

12

Protocolo de lock em duas fases (cont.)

num.locks

tempo

fase 1 fase 2

13

Protocolo de lock em duas fases (cont.)

• O protocolo garante seriação. Pode-se provar quetransações podem ser seriadas na ordem de seuspontos de lock (ponto onde transação adquiriu seuúltimo lock).

• O protocolo não garante inexistência de deadlocks.• Rollbacks em cascata são possíveis. Para evitar

rollback em cascata: protocolo de duas fases estrito -transação deve manter locks exclusivos até validar.

• Protocolo de duas fases rigoroso - todos os locksdevem ser mantidos. Transações podem ser seriadasna ordem em que são validadas.

14

Protocolo de lock em duas fases (cont.)

• Protocolo de duas fases estrito:

num.locks

tempo

fase 1 fase 2

libera locks compartihados

15

Protocolo de lock em duas fases (cont.)

• Pode haver escalonamentos seriáveis por conflito quenão podem ser obtidos quando se usa lock de duasfases.

• No entanto, na ausência de informação extra (porexemplo, ordem de acesso a dados), lock de duasfases é necessário, no seguinte sentido: Dada uma transação Ta que não obedece lock de

duas fases, podemos encontrar uma transação Tbque usa lock de duas fases, e um escalonamentopara Ta e Tb que não é seriável por conflito.

16

Conversão de locks

• Protocolo de lock em duas fases com conversão:• Fase 1:

– pode requisitar lockCp sobre dado.– pode requisitar lockEx sobre dado.– pode converter lockCp em lockEx.

• Fase 2:– pode liberar lock-Cp.– pode liberar lock-Ex.– pode converter lockEx em lockCp

17

Aquisição automática de locks

• Transação T invoca as operações padrão read/write,sem explicitar operações de lock.

• Operação read(D) é processada da seguinte forma:

if (T possue lock sobre D) read(D)else { se necessário aguarda até que nenhuma outra transação tenha um lockEx sobre D concede lockCp sobre D a T read(D)}

18

Aquisição automática de locks (cont.)

• Operação write(D) é processada da seguinte forma:

• Todos os locks são liberados após validação/aborto.

if (T possui lockEx sobre D) write(D)else { aguarda até que nenhuma outra transação tenha qualquer lock sobre D if (T possui lockCp sobre D) promove lock para lockEx sobre D else concede lockEx sobre D para T write(D)}

19

Implementação

• Servidor de locks centralizado– Fácil de gerenciar, mas… é ponto central de falha

• Servidor de locks distribuído– Resolve o problema de falha, mas… pode levar a

deadlock distribuído.

20

Protocolos baseados em timestamp

• Cada transação recebe uma timestamp (“carimbo detempo”) quando é iniciada. Uma nova transação Titem uma timestamp TS(Ti), tal que TS(Ti) > TS(Tj)para todas as transações Tj já existentes.

• Protocolo gerencia execuções concorrentes de formaque timestamps determinam a ordem de seriação.

• Mantém duas timestamps para cada dado D:• W-timestamp(D): maior timestamp de transações que

executaram write(D) com sucesso.• R-timestamp(D): maior timestamp de transações que

executaram read(D) com sucesso.

21

Protocolos baseados em timestamp (cont.)

• Protocolo garante que quaisquer operaçõesread/write conflitantes são executadas na ordem detimestamp.

• Suponha que transação T invoca read(D)– Se TS(T) < W-timestamp(D), então T necessita ler

um valor de D que já foi escrito após início de T.A operação de read é rejeitada, T é desfeita.

– Se TS(T) ≥ W-timestamp(D), operação read éexecutada. R-timestamp(D) recebe o valor max(R-timestamp(D), TS(T)).

22

Protocolos baseados em timestamp (cont.)

• Suponha que transação T invoca write(D)– Se TS(T) < R-timestamp(D), então valor que T

está produzindo foi necessário anteriormente (esistema assumiu que não existiria). A operação dewrite é rejeitada, T é desfeita.

– Se TS(T) < W-timestamp(D), então valor que Testá produzindo é obsoleto. A operação de write érejeitada, T é desfeita.

– Caso contrário, a operação de write é executada.W-timestamp(D) recebe o valor TS(T).

23

Exercício

TS-W=6TS-R=7

TS-W= TS-R=

T9: write(D)

Antes Depois ?? (complete)

24

Exercício (cont.)

TS-W=6TS-R=8

TS-W= TS-R=

T7: write(D)

Antes Depois ?? (complete)

25

Exercício (cont.)

TS-W=6TS-R=8

a) T7: read(D)b) T5: read(D)c) T9: read(D)

D: Qual o resultado em cada caso?

26

Exemplo de uso

• Escalonamento parcial, transações com timestamps1, 2, 3, 4 e 5.

T1 T2 T3 T4 T5read(X)

read(Y)read(Y)

write(Y)write(Z)

read(Z)read(Z)abort()

read(X)write(Z)abort()

write(X)write(Z)

27

Correção do protocolo baseado em timestamp

• Protocolo garante seriação, já que arestas no grafo deprecedência são da forma:

• Não há ciclos no grafo de precedência.• Não há deadlock, já que transações nunca esperam.• Escalonamento pode não ser livre de cascata, e pode

não ser recuperável.

transação comtimestamp

menor

transação comtimestamp

maior

28

Recuperação e ausência de cascata

• Problema com protocolo baseado em timestamps:– Suponha Ti aborta, mas Tj leu dado escrito por Ti.– Então Tj deve abortar; se foi permitido que Tj

tenha sido validada, escalonamento não érecuperável.

– Mais: qualquer transação que leu dado escrito porTj deve abortar.

– Isto pode levar a uma cascata de abortos.

29

Recuperação e ausência de cascata (cont.)

• Solução:– Estruturar transações de forma que operaçõeswrite são executados ao final do processamento.

– Todas as operações write formam uma açãoatômica; nenhuma transação pode executarenquanto uma outra está em fase de escrita.

– Quando uma transação aborta, ela é reiniciadacom uma nova timestamp.

30

Regra escrita de Thomas

• Uma modificação permite que operações write quesão obsoletas sejam ignoradas sob certas condições:– Quando Ti tenta escrever dado D, se

TS(Ti) < W-timestamp(D),– então Ti está escrevendo valor obsoleto. Ao invés

de abortar Ti, operação write pode ser ignorada.• Esta abordagem, conhecida como regra escrita de

Thomas (Thomas’ write rule) permite maiorpotencial para concorrência.

31

Múltiplas versões

• Esquemas com versões múltiplas mantém versõesantigas de dados para aumentar concorrência. Podemser baseados em– Ordem de timestamp– Lock de duas fases

• Cada atualização efetuada com sucesso cria umanova versão do dado.

• Timestamps são usadas para rotular versões

32

Múltiplas versões (cont.)

• Quando read(Q) é executado, o sistema selecionauma versão apropriada de Q, com base na timestampda transação.

• Desta forma, operações de read nunca sãobloqueadas, sendo executadas imediatamente.

33

Versões múltiplas com timestamp

• Cada dado Q tem uma sequência de versões <Q1, Q2,…, Qn>. Cada versão Qk contém três campos:– conteúdo - o valor da versão Qk.– R-timestamp(Qk) - timestamp da transação que

criou a versão Qk.– W-timestamp(Qk) - maior timestamp de uma

transação que leu a versão Qk.

34

Versões múltiplas com timestamp (cont.)

• Quando transação Ti cria nova versão Qk, R-timestamp e W-timestamp são inicializadas comTS(Ti).

• Quando uma transação Ti lê Qk e TS(Ti) > R-timestamp(Qk), atualiza-se a R-timestamp.

35

Versões múltiplas com timestamp (cont.)

• Suponha que transação Ti invoque uma operaçãoread(Q). Seja Qk a versão de Q cuja W-timestampseja menor ou igual a TS(Ti).

• Valor retornado é o conteúdo da versão Qk.

36

Exercício

• Qual o valor lido?

W-timestamp = 4

R-timestamp = 6

valor = 37

W-timestamp = 6

R-timestamp = 8

valor = 32

T5

Q

A) T5.read(Q) =B) T7.read(Q) =

37

Versões múltiplas com timestamp (cont.)

• Suponha que transação Ti invoque uma operaçãowrite(Q). Seja Qk a versão de Q cuja W-timestampseja menor ou igual a TS(Ti).– Se TS(Ti) <= R-timestamp(Qk), então Ti é

abortada. Senão, se TS(Ti) = W-timestamp(Qk), oconteúdo de Qk é atualizado, senão uma novaversão de Q é criada.

38

Exercício

• Complete com novas versões, conforme o caso

W-timestamp = 4

R-timestamp = 6

valor = 37

W-timestamp = 6

R-timestamp = 8

valor = 32

Ti

Q

A) T5.write(Q, 29)B) T7.write(Q, 34)C) T8.write(Q, 23)D) T9.write(Q, 42)

39

Versões múltiplas com locking

• Diferencia entre transações de leitura apenas (read-only) e transações de atualização.

• Transações de atualização adquirem locks de leiturae escrita, e os mantém até o final da execução (ouseja, transações seguem lock de duas fases).– Cada operação de write com sucesso resulta na

criação de uma nova versão do dado.– Cada versão do dado tem uma única timestamp

que é o valor de um contador ts_counter,incrementado durante o processo de validação.

40

Versões múltiplas com locking (cont.)

• A transações de leitura apenas são atribuídastimestamps com o valor corrente de ts_counter antesdo início de sua execução.

• Quando uma transação de atualização deseja ler umdado, deve obter um lock compartilhado. Então, lê aversão mais recente cria uma nova versão do itemcom timestamp = ∞.

41

Versões múltiplas com locking (cont.)

• Quando uma transação de atualização Ti completa,processo de validação faz:– Ti atribui a versões que criou a timestampts_counter+1.

– Ti incrementa ts_counter.– Transações de leitura apenas que iniciam após Ti

incrementar ts_counter acessarão valoresatualizados por Ti. As que iniciam antes doincremento acessarão valores antes da atualizaçãode Ti. Portanto, somente escalonamentos seriáveisserão produzidos.

42

Operações de inserção e remoção

• Algumas transações requerem outras operações alémde read e write. Vamos considerar outras duasoperações:– delete(Q), que remove um dado.– insert(Q), que insere um dado.

• Tentativa de executar read(Q) depois que Q tenhasido removido, ou antes que tenha sido inserido, éum erro lógico.

• Da mesma forma, é um erro tentar remover um dadoinexistente.

43

Operações de remoção

• Se ptrotocolo de lock de duas fases é utilizado, énecessário bloquear o dado com lock exclusivo antesque ele possa ser removido.

• Se protocolo de timestamp é utilizado, regra similar awrite. Suponha que Ti deseje executar delete(D):

44

Operações de remoção (cont.)

– Se TS(T) < R-timestamp(D), então valor que Tiiria remover foi lido por transação Tj com TS(Tj)> TS(Ti). A operação de delete é rejeitada, Ti édesfeita.

– Se TS(T) < W-timestamp(D), uma transação Tjcom TS(Tj) > TS(Ti), gravou D. A operação dedelete é rejeitada, Ti é desfeita.

– Caso contrário, a operação de delete é executada.

45

Operações de inserção

• Operação insert(D) conflita com delete(D), read(D)e write(D), já que nenhum dado pode ser removido,lido ou escrito antes de existir.

• Uma vez que insert(D) atribui um valor para o dadoD, operação deve ser tratada da mesma forma quewrite, tanto no protocolo de lock como no protocolode timestamp.

46

Tratamento de deadlocks

• Considere as seguintes transações:

• Escalonamento com deadlock:T1 T2

lockEx(X)write(X)B = B – 50write(B)

lockEx(Y)write(Y)wait lockEx(X)

wait lockEx(Y)

T1: write(X) write(Y)

T2: write(Y) write(X)

47

Tratamento de deadlocks (cont.)

• Sistema está em deadlock se existe um conjunto detransações tal que cada transação no conjunto estáesperando outra transação no conjunto.

• Protocolos de prevenção de deadlock garantem queo sistema nunca entrará em deadlock.

T1

T2T3

T4

48

Prevenção de deadlocks

• Algumas estratégias de prevenção:

– Pré-declaração: requer que cada transação efetuelock de todos os seus dados antes do início daexecução.

– Ordenação: Impor ordem parcial de todos osdados e requerer que uma transação efetue locknos dados somente na ordem especificada.

49

Prevenção de deadlocks (cont.)

Protocolos baseados em timestamp:• Esquema wait-die (não preemptivo):

– Transação mais antiga pode esperar por maisrecente. Transação mais recente nunca espera pormais antigas, são desfeitas.

– Problema: transação pode morrer várias vezes atéconseguir os dados desejados.

50

Prevenção de deadlocks (cont.)

Protocolos baseados em timestamp:

• Esquema wound-wait (preemptivo)– Transação mais antiga fere (força rollback)

transações mais recentes, ao invés de esperar.Transações mais recentes podem esperar portransações mais antigas.

– Potencialmente gera menos rollback do queesquema wait-die.

51

Prevenção de deadlocks (cont.)

• Tanto no esquema wait-die quanto no wound-wait,uma transação desfeita reinicia com a mesmatimestamp original. Dessa forma, transações antigastêm precendência sobre transações recentes, o queevita starvation.

52

Prevenção de deadlocks (cont.)

• Protocolo baseado em timeout:

• Uma transação espera por um lock apenas duranteum períodso especificado de tempo. Depois disso, atransação é desfeita.

• Vantagens: deadlocks não ocorrem, simples deimplementar.

• Problemas: pode ocorrer starvation, e é difícildeterminar bom valor para timeout.

53

Deteção de deadlocks

• Deadlocks podem ser descritos por um grafo deespera (wait-for graph) G = (V, E)

• V é o conjunto de vértices (todas as transações dosistema).

• E é o conjunto de arestas, cada elemento um parordenado Ti → Tj.

T1

T2T3

T4

54

Deteção de deadlocks (cont.)

Grafo de espera:• Se Ti → Tj, Ti espera que Tj libere lock de algum

dado.• Quando Ti requisita dado que Tj está utilizando,

aresta Ti → Tj é introduzida no grafo. Esta aresta éremovida apenas quando Tj libera o lock do dado.

• O sistema apresenta deadlock se e somente se existeum ciclo no grafo de espera. Deve-se então manter ografo e verificar periodicamente se apresenta ciclo.

55

Deteção de deadlocks (cont.)

• Grafos de espera:

T1

T2T3

T4

T1

T2T3

T4

T5

T5

Sem ciclo Com ciclo

56

Recuperação de deadlocks

• Quando dedlock é detectado:• Deve-se procurar uma vítima (transação que será

desfeita). Procurar selecionar a vítima que causarámenor custo; para evitar starvation, incluir númerode rollbacks no custo.

• Extensão do rollback:– Total: aborta a transação e a reinicia.– Parcial: efetuar rollback somente até o ponto onde

deadlock é quebrado.