7 - Transacoes Distribuidas 2013

Departamento de Engenharia Informática
Transacções em Sistemas
Distribuídos
Função efectuarPagamento do PagAmigo

Primeira solução
efectuarPagamento(clienteA, clienteB, Montante)
{
bancoA.LerSaldo (contaA, SaldoA);
bancoB.LerSaldo (contaB, SaldoB);
bancoA.ActualizarSaldo (contaA, saldoA-Montante);
bancoB.ActualizarSaldo (contaB, saldoB+Montante);
}
Quais os problemas desta solução?
Page 1

Solução com Transacção Atómica
{
beginTransaction;
bancoA.ActualizarSaldo (contaA, saldoA-Montante);
bancoB.ActualizarSaldo (contaB, saldoB+Montante);
commit;
}

Outra solução com Transacção Atómica
{
beginTransaction;
if (saldoA < montante)
abort;
else {
bancoA.ActualizarSaldo (contaA,saldoA-Montante);
bancoB.ActualizarSaldo
(contaB, saldoB + Montante);
commit;
}
}
Em que situações pode a transação abortar?
Page 2
Transacções Atómicas Locais

Revisão da cadeira de Bases de Dados
Sistema Transaccional
Aplicações Aplicações
Iniciar Ler
Confirmar Escrever
Abortar
Sistema Transaccional
Sistema Operativo
Hardware
Page 3
Transação
• Uma transação é uma sequência de leituras e
escritas a objetos partilhados com outras
transações
12/13 Sistemas Distribuídos 7
Propriedades das transacções – ACID

Atomicidade
• Transacção ou se executa na totalidade ou não
se executa
• O sistema tem de ser capaz de repor a situação
inicial no caso da transacção abortar (por
inciativa do programador ou falha do sistema)
Page 4

Consistência
• Uma transação é uma transformação correta
do estado.
– Supõe-se que o conjunto das ações da transação
não viola nenhuma das regras de integridade
associadas ao estado
– Isto requer que a transação seja um programa
correto

Isolamento
• Normalmente definida pela condição de
serializabilidade (serial-equivalence):
– Considere uma execução concorrente de leituras e
escritas de múltiplas transações
– A execução concorrente diz-se serializável quando
existe uma execução sequencial (das mesmas
transações) equivalente à execução concorrente
• Ou seja, cujas leituras devolvam o mesmo valor e objetos
escritos ficam com mesmo valor em ambas as execuções
(concorrente e sequencial)
Page 5

Isolamento
Esta execução concorrente é serializável?

Se sim, qual a execução sequencial equivalente?

Isolamento
Esta execução concorrente é serializável?

Se sim, qual a execução sequencial equivalente?
Page 6
Propriedades das transacções - ACID

• Durabilidade
– os resultados de uma transacção que confirmou
permanecem depois de esta acabar e sobrevivem ao
conjunto de faltas expectáveis
– Solução: resultados escritos em memória estável e
com capacidade de recuperação das faltas dos
discos que forem toleradas.
Atomic, Consistent, Isolated, Durable
Como gerir execuções concorrentes de

transações?
Page 7
Controlo de concorrência
• Solução pessimista (“pedir licença”)
– Pressupõe que os conflitos são frequentes e obriga à
prévia sincronização de todos os acessos.
Leitura Escrita
Trincos de Leitura/Escrita Leitura Compatível Conflito
Escrita Conflito Conflito
Controlo de concorrência pessimista

Sincronização em 2 fases estrita
• Cada objeto/grupo de objetos geridos por um
trinco de leitura/escrita
• Sincronização em duas fases estrita (strict two
phase locking):
– À medida que a transação vai lendo/escrevendo
sobre objetos, vai adquirindo sucessivamente os
respetivos trincos (primeira fase)
– Na terminação da transação (commit ou abort),
liberta os trincos (segunda fase)
Page 8
Controlo de concorrência pessimista

Sincronização em 2 fases estrita: exemplo
Interblocagem
• A sincronização com trincos pode conduzir a
interblocagem obrigando a mecanismos para a
resolver:
– Prevenção (ex: ordem parcial sobre trincos, adquirir todos os
trincos pela mesma ordem, caso sejam conhecidos de
antemão)
• Problema: na maior parte das vezes não é possível, e origina
quebra de desempenho
– Detecção da interblocagem
• usando temporizador – método simples , pouco preciso, mas
adequado
• ou grafo com história de sincronização das transacções (indica
recursos protegidos por trincos e as transacções que esperam por
eles)
• e obrigando a abortar as transacções
Page 9
Interblocagem: exemplo
Isolamento (cont.)
• Solução pessimista (“pedir licença”)
– Pressupõe que os conflitos são frequentes e obriga à prévia
sincronização de todos os acessos.
• Solução optimista (“pedir desculpa”)

– Considera que os conflitos são raros
– Na confirmação verifica a existência de conflitos
– Obriga a manter carimbos temporais das actualizações para
poder determinar quando há um conflito e nesse caso abortar
as transacções envolvidas
Page 10
Solução optimista
Recuperação das falhas de paragem
Page 11
Recuperação das Falhas de Paragem

• A recuperação tem de basear-se na existência
de informação redundante.
• A política de recuperação é condicionada pela
política de actualização dos dados:
– actualização directa (in-place updating) - as escritas
são efectuadas sobre os dados reais residentes nos
suportes magnéticos.
– actualização em versões (out-of-place updating) -
são criadas novas versões dos dados, preservando
os valores originais.
Actualização Directa
• A política de recuperação depende da forma como é actualizada a
cache.
• No momento da confirmação:
– Limpar a cache (cache flush) na altura da confirmação
– ou
– Manter os dados em cache
• No momento da escrita de dados
– Permitir a escrita de dados de transacções activas na memória
persistente.
– ou
– Manter os dados das transacções activas apenas em memória volátil
(gestão assíncrona)
• Necessário manter informação redundante no ficheiro de diário (log)
• A informação a manter depende destas decisões
Page 12
Write Ahead Logging

• A gestão assíncrona da cache é sempre mais
eficiente e permite gerir melhor a memória
volátil.
• Neste caso o diário tem de conter informação
para fazer e desfazer o resultado das operações
(redo/undo)
• É também necessário garantir que a
informação é escrita no diário antes da
modificação das páginas (write-ahead logging)
Actualização em Versões:
Páginas sombra (Shadow pages)
• Copia-se inicialmente a tabela de páginas de modo a poder
reconstituir a versão
• Se a transacção confirmar é necessário comutar atomicamente o
ficheiro no directório
• A dispersão de ficheiros pelo disco e a proliferação de versões são
limitações deste método.
Page 13
Gestão do Diário
• Aspectos a considerar
– Registos: físicos ou lógicos
– Robustez do diário a falhas dos discos
– Escrita síncrona/assíncrona dos registos
– Redução do espaço do ficheiro do diário através de
marcas de recuperação (checkpointing)
– Faltas durante a recuperação
Exemplo de Diário
Page 14
Arquitectura do Sistema Transaccional

• Gestor de Sincronização
– é responsável pela sincronização de todos os acessos aos dados
manipulados pelas transacções. Deve, portanto, ser chamado em
todas as situações de leitura ou escrita para gerir os trincos
associados aos objectos e tratar os problemas de interblocagem.
• Gestor da cache
– gere a relação entre os discos e a memória volátil. A optimização é
obtida, evitando tanto quanto possível executar escritas síncronas e
agrupando escritas em bloco para o disco.
• Gestor do Diário (Log)
– gere a informação redundante. Esta informação é mantida numa lista
que regista as operações relevantes de actualização da estrutura de
dados.
– O diário é na realidade um ficheiro escrito sequencialmente, o que
garante que a informação é registada segundo a ordem de execução
das operações.
Page 15

• Gestor da recuperação
– recupera o sistema para um estado consistente
sempre que uma falta for detectada. A gestão da
cache, a informação escrita no diário e o algoritmo
de recuperação estão intimamente relacionados
• Gestor da memória estável
– garante a persistência dos dados.
– fornece uma abstracção de memória persistente,
capaz de manter a informação mesmo quando
existem falhas dos discos.
Transacções Atómicas
Distribuídas
Page 16
Transacções distribuídas:
Modelo de Faltas
• Distribuição implica lidar com:
– Falta dos discos
– Falta das máquinas Faltas de Paragem
– Falta das comunicações
• O modelo de faltas tem de considerar diversas

simplificações
– Sistemas: apenas faltas de paragem não se consideram faltas
bizantinas
– Modelo funciona num sistema assíncrono (tempo de propagação
das mensagens pode ser arbitrariamente longo)
– Faltas temporárias de comunicação toleradas pelos protocolos de
transporte, não se consideram faltas permanentes da rede
(partições)
PapelopenTransaction
do Coordenador join participant
closeTransaction
A a.withdraw(4);
.
join
BranchX
T
participant
b.withdraw(T, 3);
Client B b.withdraw(3);
T = openTransaction
join BranchY
a.withdraw(4);
c.deposit(4); participant
b.withdraw(3);
d.deposit(3); C c.deposit(4);
closeTransaction
D d.deposit(3);
Note: the coordinator is in one of the servers, e.g. BranchX BranchZ
Só quando é chamado closeTransaction se executa o protocolo

para confirmar ou abortar a transacção atomicamente
Page 17
Protocolo de confirmação em
duas fases
Two-Phase Commit (2PC)
Problemas a considerar
• A tomada de decisão de abortar ou confirmar
uma transacção é o problema mais complexo a
resolver
• Requer um consenso entre os diferentes

participantes numa transacção distribuída
Page 18
Protocolo (sem falhas)
Coordinator Participant
step status step status

canCommit?
1 prepared to commit
(waiting for votes) Yes 2 prepared to commit
3 committed doCommit (uncertain)
haveCommitted 4 committed
done
Protocolo (sem falhas)

Coordenador Participante i
Envia PREPARAR a todos
Envia votoi ao coord.
if (votoi == não)
decisãoi = abort
if (todos votaram sim) exit
decisãocoord = commit
Envia COMMIT a todos
else
decisãocoord = abort
Envia ABORT a todos que votaram sim
exit
if (recebe ABORT)
decisãoi = abort
else
decisãoi = commit
exit
Page 19
Interacção Cliente-Coordenador
API do Coordenador
openTransaction() -> trans;
starts a new transaction and delivers a unique TID trans. This
identifier will be used in the other operations in the transaction.
closeTransaction(trans) -> (commit, abort);

ends a transaction: a commit return value indicates that the
transaction has committed; an abort return value indicates that
it has aborted.
abortTransaction(trans);
aborts the transaction.
Operações no 2PC
canCommit?(trans)-> Yes / No
Call from coordinator to participant to ask whether it can commit a
transaction. Participant replies with its vote.
doCommit(trans)
Call from coordinator to participant to tell participant to commit its part of a
transaction.
doAbort(trans)
Call from coordinator to participant to tell participant to abort its part of a
transaction.
haveCommitted(trans, participant)
Call from participant to coordinator to confirm that it has committed the
transaction.
getDecision(trans) -> Yes / No
Call from participant to coordinator to ask for the decision on a transaction
after it has voted Yes but has still had no reply after some delay. Used to
recover from server crash or delayed messages.
Page 20
2PC - diagramas de interacções
begin W diário preparar Espera
commit Envia mensagem
Espera Pronto?
W diário S
abort
Envia mensagem
diário Todas?
W diário
S ready
Envia mensagem
Um Não?
S W diário
commit
Envia mensagem
Espera
W diário
abort
Envia mensagem
diário
Abortar?
S
Espera W diário commit
W diário abort
Todas?
S
end Termina transacção Envia mensagem
2008/2009 José Alves Marques, Rodrigo Rodrigues e João Barreto
Logs do protocolo
Evento Info. escrita no log Instante da escrita
Coord. envia PREPARAR Begin commit Em paralelo com envio

• Assume
Participante vota sim
um diário (log) persistente
Sim
com escritas
Antes de enviar voto
atómica
Participante vota não Não Em paralelo com envio
Coord. decide commit Commit Antes de enviar commit
Coord. decide abort Abort Em paralelo com envio
Particip. recebe decisão Commit ou Abort Em paralelo com decisão
Page 21
Diagrama de Estados - Coordenador

A detecção de faltas de temporizador
inicial expirou
paragem é por timeout
coordenador pode logo tomar a
decisão de abortar ou tentar Input: -
contactar novamente os Output: Envia PREPARAR a todos
participantes
espera
Input: Recebe um ou mais NÃO Input: Recebe SIM de todos
Ou temporizador expira Output: Envia COMMIT a todos
Output: Envia ABORT a todos
abort commit
Diagrama de Estado - Participante

temporizador
expirou
inicial
Input: (Recebe PREPARAR
e votoi == não) Input: Recebe PREPARAR e votoi == sim
Ou temporizador expira Output: Envia sim ao coordenador
Output: Envia não ao coord.
Executar protocolo de
Preparado terminação
Input: Recebe COMMIT

Input: Recebe
ABORT
abort commit
Page 22
Tolerância a faltas no 2PC
• Não recepção de mensagens
– Detectadas com um temporizador no Coordenador ou nos
Participantes
• Timeout no Coordenador
– Estado Esperar
• Não pode confirmar unilateralmente a transacção
• Mas pode unilateralmente optar por abortar a transacção
– Se considerar que o atraso na resposta se deve a uma falta
– Estados Abortar e Confirmar
• O Coordenador não pode terminar a transacção
– Tem que receber a confirmação de todos os Participantes
• Pode repetir a mensagem global previamente enviada
Tolerância a faltas no 2PC
• Timeout num Participante

– Estado Inicial
•Pode optar unilateralmente por abortar a transacção
•Ou verifica o estado do Coordenador
– Estado Preparado
•Não pode progredir
–Depende da decisão do Coordenador que já influenciou
–A transacção fica activa e bloqueada até se saber essa decisão
•Se os Participantes interactuarem é possível evoluir
»Obtendo a decisão do coordenador que chegou aos outros Participantes
•Falha permanente do Coordenador (apenas)
–Protocolos de eleição de um novo Coordenador
Page 23
Recuperação depois de falta de paragem

• Recuperação do Coordenador
– Estados Inicial e Esperar
• Repete as mensagens de Preparação para obter
novamente a votação dos TMs
– Estado Confirmar ou Abortar
• Se ainda não recebeu todas as confirmações repete o
envio da mensagem global previamente enviada
• Recuperação de um Participante
– Estado Inicial
• Aborta unilateralmente a transacção
– Estado Preparado
• Reenvia o seu voto (sim ou não) para o Coordenador
Problemas do 2PC
• O protocolo é bloqueante:
– Obriga os Participantes a esperar pela recuperação
do Coordenador
– E vice-versa
• Não é possível fazer uma recuperação
totalmente independente
• Há alternativas não-bloqueantes
– Sob modelos de faltas mais restritivos
– Normalmente muito mais complexas (ex. 3PC)
Page 24
Transacções distribuídas
Arquitectura X/Open
Consórcio X/OPEN
• Esforço de normalização dos protocolos e
interfaces para interligação de sistemas de
informação heterogéneos
– DTP (Distributed Transaction Processing)
– Muito influenciado pela norma de facto que
constituiu a arquitectura SNA da IBM e a sua
interface LU 6.2
Page 25
Arquitectura X/Open
• Gestores de Recursos - RM (resource manager)
– Armazenam os dados
• Em BDs relacionais, sistemas de ficheiros com actualizações
atómicas, etc.
– Garantem localmente as propriedades das transacções
• Monitores Transaccionais - TM (transaction managers)
– Coordenadores dos RM
• Através da interface XA
– Execução dos protocolos de iniciação/terminação das
transacções
– Um em cada máquina (ou em cada grupo de máquinas)
Transacções distribuídas X/Open
Iniciar
Confirmar
TM
Abortar
Preparar
Associar Confirmar
Aplicação Abortar
Ler
Escrever
RM
Page 26
X/Open (com distribuição)
TM TM
Aplicação SC SC
RM RM
X/Open
• Uma aplicação inicia uma transacção
– Invoca o TM local que lhe atribui um identificador único
• A aplicação contacta em seguida os RMs
– Para efectuar as operações de leitura e escrita
– Usa o identificador da transacção
• Os RMs associam-se à transacção
– Quando um RM recebe a primeira operação relacionada com uma
transacção desconhecida contacta o TM local para se associar à
transacção
• A transacção termina
– Todos os TM envolvidos executam um protocolo de consenso
distribuído
Page 27
TP-Monitor components (generic)

Administration and operations interfaces
persistent
queue Monitor services
client
Authentication
scheduling load balancing program
library
client queues server class
Presentation services
binding context context

client
database
data internal
dictionary Application Log Recovery resource
program manager manager managers
persistent
queue
external
database resource
manager
From “Transaction Processing” Gray&Reuter. Morgan Kaufmann 1993
Monitor Transaccional Tuxedo da BEA
X/Open DTP Reference Model Tuxedo System in DTP Model

Application Program (AP) C, COBOL, 4GLs or CASE appllications
TX API XATMI or TX API

XATMI or
CPI-C or
TxRPC
TxRPC or
Peer-toPeer SQL
C-ISAM or SQL or
Other Transaction System /T
Manager (TM) Unix System V
XA
XA+
+
Communication
XA XA System /T
Resource Manager
Communications
(CRM)
XAP-TP
XAP-TP
Resource XA-Compliant
OSI-TP OSI-TP
Manager (RM) Resouce Manager
Page 28

7 - Transacoes Distribuidas 2013

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

7 - Transacoes Distribuidas 2013

Enviado por

Direitos autorais:

Formatos disponíveis

Departamento de Engenharia Informática

Departamento de Engenharia Informática

Função efectuarPagamento do PagAmigo

Quais os problemas desta solução?

Função efectuarPagamento do PagAmigo

Departamento de Engenharia Informática

Função efectuarPagamento do PagAmigo

Transacções Atómicas Locais

Departamento de Engenharia Informática

12/13 Sistemas Distribuídos 7

Departamento de Engenharia Informática

Propriedades das transacções – ACID

Propriedades das transacções – ACID

12/13 Sistemas Distribuídos 9

Departamento de Engenharia Informática

Propriedades das transacções – ACID

Propriedades das transacções – ACID

Esta execução concorrente é serializável?

Departamento de Engenharia Informática

Propriedades das transacções – ACID

Esta execução concorrente é serializável?

Propriedades das transacções - ACID

Atomic, Consistent, Isolated, Durable

Departamento de Engenharia Informática

Como gerir execuções concorrentes de

12/13 Sistemas Distribuídos 18

Departamento de Engenharia Informática

Controlo de concorrência pessimista

Controlo de concorrência pessimista

12/13 Sistemas Distribuídos 25

Departamento de Engenharia Informática

Departamento de Engenharia Informática

• Solução optimista (“pedir desculpa”)

Departamento de Engenharia Informática

Recuperação das falhas de paragem

12/13 Sistemas Distribuídos 30

Recuperação das Falhas de Paragem

Departamento de Engenharia Informática

Write Ahead Logging

Departamento de Engenharia Informática

Departamento de Engenharia Informática

Arquitectura do Sistema Transaccional

12/13 Sistemas Distribuídos 37

Departamento de Engenharia Informática

Arquitectura do Sistema Transaccional

Arquitectura do Sistema Transaccional

Departamento de Engenharia Informática

• O modelo de faltas tem de considerar diversas

Departamento de Engenharia Informática

Só quando é chamado closeTransaction se executa o protocolo

Departamento de Engenharia Informática

• Requer um consenso entre os diferentes

Protocolo (sem falhas)

step status step status

Departamento de Engenharia Informática

Protocolo (sem falhas)

closeTransaction(trans) -> (commit, abort);

Departamento de Engenharia Informática

end Termina transacção Envia mensagem

2008/2009 José Alves Marques, Rodrigo Rodrigues e João Barreto

Departamento de Engenharia Informática

Evento Info. escrita no log Instante da escrita

Coord. envia PREPARAR Begin commit Em paralelo com envio

Coord. decide commit Commit Antes de enviar commit