Upload
ngokhue
View
213
Download
0
Embed Size (px)
Citation preview
Transações
Na última aula...
Transação: Unidade lógica de trabalho • abrange um conjunto de operações de manipulação de dados que executam uma única tarefa
Conecta ao Banco de Dados
Começa transação
Operações de consulta/atualização
...
Finaliza transação
Começa transação
Operações de consulta/atualização
...
Finaliza transação
Desconecta
DECSI/ICEA UFOP
2
Controle de Concorrência
• Execução Serial (sequencial):
• Execução Intercalada:
tempot2t1 t3
AB
tempot2t1 t3
AB
AB
t4 t5
DECSI/ICEA UFOP
3
Regras para conflito das operações read e write
Operações que dependem da ordem em que foram executas
DECSI/ICEA UFOP
Operações das váriastransações
Conflito Razão
read read Não Porque um par de operações de leitura não dependem da ordem em que foram executadas
read write Sim A ordem altera o resultado final
write write Sim A ordem altera o resultado final
4
Transações Distribuídas
• Transação Distribuída: • transação cujas operações devem ser executadas em várias das estações de uma rede.• Envolve atualização de dados em múltiplos BD
• Exemplo: transferência bancária de uma conta localizada em uma agência A para uma agência B• UPDATE A.conta SET saldo= saldo 100 WHERE num = 49950;
• UPDATE B.conta SET saldo= saldo + 100 WHERE num = 80410;
• COMMIT;
DECSI/ICEA UFOP
5
Transações Distribuídas
• Dificuldade: garantia global de atomicidade• Ou todos servidores efetivam a transação (commit)
• Ou transação é abortada em todos os servidores
• Solução: Protocolo para Garantia de Atomicidade (Atomic Commit Protocol)
DECSI/ICEA UFOP
6
Transações Distribuídas planas e aninhadas
DECSI/ICEA UFOP
7
(a) Transação plana (b) Transação aninhada
Cliente
X
Y
Z
X
Y
M
NT1
T2
T11
Cliente
P
TT12
T21
T22
T
T
Transações Distribuídas:Transação bancária aninhada
DECSI/ICEA UFOP
8
a.withdraw(10)
c.deposit(10)
b.withdraw(20)
d.deposit(20)
Cliente A
B
C
T1
T2
T3
T4
T
D
X
Y
Z
T = openTransactionopenSubTransaction
a.withdraw(10);
closeTransaction
openSubTransactionb.withdraw(20);
openSubTransactionc.deposit(10);
openSubTransactiond.deposit(20);
Coordenando uma Transação distribuída
DECSI/ICEA UFOP
9
..
AgênciaZ
AgênciaX
participante
participante
C
D
Cliente
AgênciaY
B
A
participantejoin
join
join
T
a.withdraw(4);
c.deposit(4);
b.withdraw(3);
d.deposit(3);
openTransaction
b.withdraw(T, 3);
closeTransaction
T = openTransactiona.withdraw(4);c.deposit(4);b.withdraw(3);d.deposit(3);
closeTransaction
Note: O Coordenador é um dos servidores, ex. AgênciaX
Protocolos de confirmação atômica• Devem garantir que uma transação foi concluída com sucesso ou falhar
• Protocolo de confirmação de uma fase:• Coordenador comunica pedido de confirmação ou cancelamento para todos os participantes
• Repete até que todos confirmem que seguiram o pedido
DECSI/ICEA UFOP
13
Protocolos de confirmação atômica• Devem garantir que uma transação foi concluída com sucesso ou falhar
• Protocolo de confirmação de uma fase:• Coordenador comunica pedido de confirmação ou cancelamento para todos os participantes
• Repete até que todos confirmem que seguiram o pedido
DECSI/ICEA UFOP
14
Por quê é inadequado?
Protocolos de confirmação atômica• Devem garantir que uma transação foi concluída com sucesso ou falhar
• Protocolo de confirmação de uma fase:
DECSI/ICEA UFOP
15
Por quê é inadequado?
Não permite que um servidor tome uma decisão unilateral de cancelar uma transação
Two Phase Commit Protocol (2PC)
• Protocolo para garantia de atomicidade de transações distribuídas
• Executado em todas as estações que tomam parte de uma transação distribuída
• Supõe a existência de um nodo coordenador, o qual é responsável pelo monitoramento da transação distribuída• Normalmente, é o próprio nodo que disparou a transação
• Duas fases:• Fase 1: Votação
• Fase 2: Apuração
• Suposição: transações já foram disparadas para os n nodos participantes
DECSI/ICEA UFOP
16
2PC: Fase 1 (Votação)
• Coordenador envia mensagem Prepare(CanCommit) para todos os participantes
• Participante responde com um Sim ou Não.
• Em caso de resposta Não, participante descarta transação.
DECSI/ICEA UFOP
17
2PC: Fase 2 (Apuração)
• Têm início após o recebimento de n votos
• Caso todos os votos sejam Sim• Coordenador envia mensagem doCommit para todos os
participantes, que então realizam commit e respondem com um haveCommited (acks)
• Após receber n haveCommited, coordenador sinaliza sucesso da transação
• Caso haja um único voto Não• Coordenador envia doAbort para todos os participantes, que
então abortam a transação
• Após receber n haveCommited, coordenador finaliza protocolo
DECSI/ICEA UFOP
18
Comunicação no 2PC
DECSI/ICEA UFOP
19
canCommit?
Yes
doCommit
haveCommitted
Coordenador
1
3
(waiting for votes)
committed
done
prepared to commit
passo
Participante
2
4
(uncertain)
prepared to commit
committed
estadopassoestado
Comunicação no 2PC
DECSI/ICEA UFOP
20
canCommit?
Yes
doCommit
haveCommitted
Coordenador
1
3
(waiting for votes)
committed
done
prepared to commit
passo
Participante
2
4
(uncertain)
prepared to commit
committed
estadopassoestado
Quantas mensagens são necessárias?
2PC: Número de Mensagens Trocadas• Observações:• Nodos não podem alterar seu voto• Um único Não tem poder de veto
• Número de mensagens trocadas:• n mensagens do tipo CanCommit• n mensagens contendo os votos dos participantes• n mensagens doAbort ou doCommit• n haveCommited
• Total de mensagens: 4n
• O protocolo poderia funcionar sem as msghaveCommited
DECSI/ICEA UFOP
21
2PC: Tratamento de Falhas
• Coordenadores e participantes entram em alguns estados em que ficam esperando mensagens uns dos outros
• E se estas mensagens não chegarem ?• Devido, por exemplo, a problemas na rede
• Soluções: timeout, para abandonar estado de espera
• Após o timeout:• Abortar a transação
• Reenviar uma mensagem
DECSI/ICEA UFOP
22
2PC: Situações Possíveis de Falhas
• Situação 1: Coordenador esperando voto de um ou mais participantes
• Se voto não chegar dentro de um certo intervalo de tempo (timeout), coordenador aborta a transação
• Deve enviar antes mensagem doAbort para todos os participantes
DECSI/ICEA UFOP
23
2PC: Situações Possíveis de Falhas
• Situação 2: Coordenador esperando ACK de participante
• Se ACK não chegar dentro de um certo intervalo de tempo (timeout), deve reenviar mensagem doCommit ou doAbort e então voltar a esperar um ACK.
• Veja que, neste caso, coordenador permanece bloqueado, esperando ACK.
DECSI/ICEA UFOP
24
2PC: Situações Possíveis de Falhas
• Situação 3: Participante que votou Sim e que encontrase esperando doCommit ou doAbort• Não pode tomar uma decisão unilateral (exemplo: reverter
seu voto para Não)
• Deve permanecer bloqueado, aguardando resultado da transação
• Logo, falhas têm os seguintes efeitos sobre o Protocolo 2PC• Podem requerer retransmissão de mensagens
• Podem dar origem a bloqueios
DECSI/ICEA UFOP
25
Uma variante descentralizada do 2PC
• Os participantes se comunicam diretamente uns com os outros, em vez de indiretamente por meio do coordenador.
• Na fase 1, o coordenador envia seu voto para todos os participantes. • Na fase 2, se o voto do coordenador for Não, os participantes apenas cancelam a transação; • se for Sim, cada participante envia seu voto para o coordenador e para os
outros participantes, cada um dos quais decide sobre o resultado, de acordo com o voto, e o executa.
1. Calcule o número de mensagens e o número de rodadas necessárias para isso.
2. Quais são as vantagens ou desvantagens, em comparação com a variante centralizada?
DECSI/ICEA UFOP
26
Uma variante descentralizada do 2PC
• Número de mensagens:• Fase 1: Coordenador envia seu voto para N participantes = N• Fase 2: cad N participante envia seu voto para os outros (N1) participantes + coordenador = N*(N 1).
• Total = N*N.• No. rodadas:• Cada participante + coordenador = 2 rodadas.• Vantagens:O número de rodadas é menor.
• Desvantagem: A quantidade de mensagens N*N aoinvés de 3N
DECSI/ICEA UFOP
27
2PC: Implementações
• SGBD com suporte a distribuição de dados:• Exemplos: Oracle, Microsoft SQL Server, IBM DB2 etc
• Monitores de Transação:• Componente essencial em um sistema/cliente servidor de 3
camadas que necessita acessar diversos BD
• Principais tarefas:
• Garantir atomicidade de transações distribuídas (geralmente via 2PC)
• Multiplexar carga de acesso a um SGBD
• Exemplos: Microsoft Transaction Server (MTS), BEA Tuxedo, IBM Encina, Java Transaction Server etc
DECSI/ICEA UFOP
28
Microsoft Transaction Server (MTS)
Ap lic ação
Ap lic ação
Ap lic ação
M ic r o s o f t T r an s ac tio n S er v er
C lien te
C lien te
C lien te
T er m in a isT e le f ô n ic o s
C lien tes
D is tr ib u ted T r an s ac tio n C o o r d in a to r
• Aplicações: objetos DCOM (objetos cujos métodos podem ser chamados remotamente a partir de clientes)
• Exemplo de aplicação: Cadastrar um novo cliente em uma empresa de telecomunicações (envolve inserções em dois bancos de dados: terminais telefônicos e clientes)
DECSI/ICEA UFOP
29
Padrões para Transações Distribuídas• Objetivo: padronizar serviços de transações distribuídas, de forma a permitir interoperabilidade entre:• Aplicação e Monitor de Transação
• Monitor de Transação e SGBD
• Principal padrão: Distributed Transaction Processing (DTP)• Proposto pelo consórcio X/Open
DECSI/ICEA UFOP
30
Interfaces do Padrão DTP
• Interface TX: padroniza interface entre aplicação e monitor de transação• Principais funções: tx_begin, tx_commit, tx_rollback, tx_open,
tx_close etc
• Suportada pelos principais monitores de transação, a exceção do MTS
• Interface XA: padroniza interface de comunicação entre monitor de transação e SGBD (gerenciador de recursos)• Principais funções: xa_prepare, xa_commit etc (mensagens
trocadas no protocolo 2PC)
• Suportada pelos principais monitores de transação (inclusive MTS) e pelos principais SGBDs.
DECSI/ICEA UFOP
31
Controle de Concorrência em transações Distribuídas
• Travamento
• Ordenação por carimbo de tempo
• Controle de concorrência otimista
DECSI/ICEA UFOP
32
Controle de Concorrência em transações Distribuídas
• Ordenação por carimbo de tempo• Coordenador publica um timestamp para cada transação
• Timestamp deve ser globalmente exclusivo
• Servidores garantem que cada transação é executada sequencialmente
DECSI/ICEA UFOP
35
Controle de Concorrência em transações Distribuídas
• Ordenação por carimbo de tempo
• Transação T e U acessam um mesmo objeto• U Acessa o objeto após T
• Usando Timestamp <timestamp, id_servidor>
• Servidores confirmaram nesta ordem
• Exige certa sincronização de relógios
DECSI/ICEA UFOP
36
Controle de Concorrência em transações Distribuídas
• Controle de concorrência otimista• Cada transação é validada antes de ser confirmada
• Cada transação tem um identificador
• As transações são executadas nesta ordem
DECSI/ICEA UFOP
37
Controle de Concorrência em transações Distribuídas
• Controle de concorrência otimista• Cada transação é validada antes de ser confirmada
• Cada transação tem um identificador
• As transações são executadas nesta ordem
• Problema• Pode levar a um impasse quando quando dois servidores começarem transações simultaneamente
DECSI/ICEA UFOP
38
Controle de Concorrência em transações Distribuídas
• Controle de concorrência otimista
DECSI/ICEA UFOP
39
Nenhum servidor poderá
confirmar, porque um está esperando a
confirmação do outro
Deadlocks (impasses) distribuídos
DECSI/ICEA UFOP
40
• Um deadlock ou impasse pode ocorrer porque as transações esperam uma pela outra
• Uma transação está em “deadlock” se está bloqueada e permanecerá assim até que ocorra uma intervenção externa
• Algoritmos de CC baseados em bloqueio podem resultar em impasses
• Algoritmos de ordenação de timestamp que exigem a espera de transações também podem causar impasses
Deadlocks (impasses) distribuídos
DECSI/ICEA UFOP
41
• Grafo de espera (Waitfor graph – WFG)
• Existe um arco Ti →Tj no WFG se a transação Ti estiver esperando que outra transação Tj libere um bloqueio sobre alguma entidade.
• Há um impasse se há ciclo no grafo
Deadlocks (impasses) distribuídos
• Travamento
DECSI/ICEA UFOP
42
U V W
d.deposit(10) lock D
b.deposit(10) lock B
a.deposit(20) lock A at Y
at X
c.deposit(30) lock C
b.withdraw(30) wait at Y at Z
c.withdraw(20) wait at Z
a.withdraw(20) wait at X
Deadlocks (impasses) distribuídos
DECSI/ICEA UFOP
43
D
Esperapor
Esperapor
Mantido por
Mantido por
BEsperapor
Mantido por
X
Y
Z
Mantido por
W
UV
AC
Deadlocks (impasses) distribuídos
DECSI/ICEA UFOP
44
D
Esperapor
Esperapor
Mantido por
Mantido por
BEsperapor
Mantido por
X
Y
Z
Mantido por
W
UV
AC W
V
U
Formação do ciclo
Exercício
Construa o grafo de espera por das transações abaixo. Está ocorrendo um impasse?
DECSI/ICEA UFOP
45
Detecção de impasses
• Ignorar• Deixe que o programador da aplicação lide com ele, ou reinicie o sistema
• Prevenção• Garantir que os impasses nunca ocorram. Gerenciador de transações verifica uma transação quando ela é iniciada e não permite que elaprossiga se houver possibilidade de impasse. Não exigem suporte em tempo de execução. Não adequada p/ SGBD
• Anulação• Detectam situações potenciais de impasse com antecedência e asseguram que eles não ocorrerão (ordem prédefinida, timestamp). Exigem suporte em tempo de execução.
• Detecção e Recuperação (mais usual)• Permitem que impasses ocorram, detectamnos monitorando formação de ciclos no WFG e rompendoos. Exigem suporte em tempo de execução
DECSI/ICEA UFOP
46
Detecção de impasse centralizada
• Servidor assume papel detector de impasse global
• Cada servidor envia seu grafo de espera local
DECSI/ICEA UFOP
47
X
T U
Y
V TT
U V
Grafo de espera local Grafo de espera local Detector de impasse global
Detecção de impasse centralizada
• Por que a solução centralizada não é uma boa idéia?
DECSI/ICEA UFOP
48
Detecção de impasse centralizada
• Por que a solução centralizada não é uma boa idéia?
• Falta de tolerância a falhas
• Escalabilidade
• Como decidir a frequência de construção do grafo?
• Se frequente, Custo para enviar grafo de espera local pode ser alto
• Senão, pode demorar para detectar um impasse
DECSI/ICEA UFOP
49
Problema do impasse fantasma
• Detecta um impasse que não é impasse
DECSI/ICEA UFOP
51
Considere a seguinte mudança:U Libera objeto em XU Solicita objeto mantido em V servidor Y
X
T U
Y
V T
Problema do impasse fantasma
• Detecta um impasse que não é impasse
DECSI/ICEA UFOP
52
Considere a seguinte mudança:U Libera objeto em XU Solicita objeto mantido em V servidor Y
X
T U
Y
V TT
U V
Detecção de impasse distribuído
• Caminhamento pelas arestas (Edge Chasing)• Servidores têm conhecimento de algumas arestas
• Tentam encontrar ciclos encaminhando mensagens de sondagem• Mensagem representa relacionamentos espera por datransação
DECSI/ICEA UFOP
53
Caminhamento pelas arestas
Algoritmo em três etapas• Início:
• servidor nota que uma transação T começa a esperar por outra transação U
• Envia uma mensagem de sondagem contendo a aresta <T→ U> para o servidor do objeto em que a transação U está parada
• Detecção• consiste no recebimento de mensagens de sondagem e em decidir se o impasse ocorreu e se as mensagens de sondagens devem ser encaminhadas.
• Solução• quando um ciclo é detectado, uma transação do ciclo é cancelada para desfazer o impasse
DECSI/ICEA UFOP
54
Caminhamento pelas arestasO servidor X inicia a detecção, enviando a mensagem de sondagem <W → U> para o servidor de B (servidor Y).
DECSI/ICEA UFOP
55
Esperapor
Esperapor
Mantido por
Mantido por
BEsperapor
Mantido por
X
Y
Z
W
UV
AC
Caminhamento pelas arestasO servidor X inicia a detecção, enviando a mensagem de sondagem <W → U> para o servidor de B (servidor Y).
DECSI/ICEA UFOP
56
Esperapor
Esperapor
Mantido por
Mantido por
BEsperapor
Mantido por
X
Y
Z
W
UV
AC
Caminhamento pelas arestas• O servidor Y recebe a mensagem de sondagem <W → U>, nota que B é mantido por V e anexa V na mensagem de sondagem para produzir
<W → U → V>.
• Ele nota que V está esperando por C no servidor Z.
• mensagem de sondagem é encaminhada para o servidor Z.
DECSI/ICEA UFOP
57
Esperapor
Esperapor
Mantido por
Mantido por
BEsperapor
Mantido por
X
Y
Z
W
UV
AC
Caminhamento pelas arestas• O servidor Y recebe a mensagem de sondagem <W → U>, nota que B é mantido por V e anexa V na mensagem de sondagem para produzir
<W → U → V>.
• Ele nota que V está esperando por C no servidor Z.
• mensagem de sondagem é encaminhada para o servidor Z.
DECSI/ICEA UFOP
58
Esperapor
Esperapor
Mantido por
Mantido por
BEsperapor
Mantido por
X
Y
Z
W
UV
AC
Caminhamento pelas arestas• O servidor Z recebe a mensagem de sondagem <W → U → V>,
• nota que C é mantido por W e anexa W na mensagem de sondagem
• <W → U → V → W>.
DECSI/ICEA UFOP
59
Esperapor
Esperapor
Mantido por
Mantido por
BEsperapor
Mantido por
X
Y
Z
W
UV
AC
Caminhamento pelas arestas• O servidor Z recebe a mensagem de sondagem <W → U → V>,
• nota que C é mantido por W e anexa W na mensagem de sondagem
• <W → U → V → W>
Ciclo detectado.
DECSI/ICEA UFOP
60
Esperapor
Esperapor
Mantido por
Mantido por
BEsperapor
Mantido por
X
Y
Z
W
UV
ACImpassedetectado
Caminhamento pelas arestas
• Antes que um servidor transmita uma mensagem de sondagem para outro servidor, ele consulta o coordenador da última transação no caminho para descobrir se ela está esperando por outro objeto de alguma parte
• O algoritmo deve encontrar qualquer ocorrência de impasse• desde que as transações que estão esperando não sejam canceladas
• não existam falhas como mensagens perdidas ou servidores falhando.
DECSI/ICEA UFOP
61
Caminhamento pelas arestas
• Antes que um servidor transmita uma mensagem de sondagem para outro servidor, ele consulta o coordenador da última transação no caminho para descobrir se ela está esperando por outro objeto de alguma parte
• O algoritmo deve encontrar qualquer ocorrência de impasse• desde que as transações que estão esperando não sejam canceladas
• não existam falhas como mensagens perdidas ou servidores falhando
DECSI/ICEA UFOP
62
Caminhamento pelas arestas
• Uma mensagem de sondagem que detecta um ciclo envolvendo N transações • será encaminhada por (N – 1) coordenadores de transação por intermédio de (N – 1) servidores de objetos,
• Logo, exigindo 2(N – 1) mensagens.
• A maioria dos impasses envolve ciclos contendo apenas duas transações• não há necessidade de preocupação excessiva com o número de mensagens envolvidas.
DECSI/ICEA UFOP
63
Prioridades de transação
• Se dois servidores começam a detecção de impasse simultaneamente • Mais de uma transação pode ser cancelada
DECSI/ICEA UFOP
64
Prioridades de transação
• Se dois servidores começam a detecção de impasse simultaneamente • Mais de uma transação pode ser cancelada
DECSI/ICEA UFOP
65
(a) Situação inicial (b) Detecção iniciada por T (c) Detecção iniciada por W
U
T
V
W
Espera por
Espera por
V
W
U
T
T U W VT U W
T UEspera por
UV
T
W
W V TW V T U
W VEspera por
→
→ →→ →
→ →→ → →
→
Prioridades de transação
• Prover prioridade para transações• T > U > V > W• Ao detectar ciclo,W é cancelada
DECSI/ICEA UFOP
66
(a) Situação inicial (b) Detecção iniciada por T (c) Detecção iniciada por W
U
T
V
W
Espera por
Espera por
V
W
U
T
T U W VT U W
T UEspera por
UV
T
W
W V TW V T U
W VEspera por
→
→ →→ →
→ →→ → →
→
Reforçando
• Supondo que esteja em uso o travamento de duas fases restrito, descreva como as ações do protocolo de confirmação de duas fases se relaciona com as ações de controle de concorrência de cada servidor individual.
• Como a detecção de impasse distribuído se encaixa nisso?
DECSI/ICEA UFOP
67
Reforçando
• Dado o conjunto de Transações abaixo ordene utilizando travamento em duas fases
• Desenhe o grafo de espera por da sua solução
DECSI/ICEA UFOP
68
U V
leia(A)
escreva(A)
W
escreva(A)escreva(B)escreva(C)
leia(A)
leia(B)
leia(C)