Transacções em Sistemas Distribuídosdisciplinas.ist.utl.pt/~leic-sod.daemon/2012-2013-sem2/teoricas... · associados aos objectos e tratar os problemas de interblocagem. • Gestor

1

Page 1

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?

2

Page 2



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?

3

Page 3


Transacções Atómicas Locais

Revisão da cadeira de Bases de Dados


Sistema Transaccional

Aplicações

Sistema Transaccional

IniciarConfirmarAbortar

LerEscrever

Sistema Operativo

Hardware

Aplicações

4

Page 4


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)

5

Page 5



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)

6

Page 6



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?

7

Page 7


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?


8

Page 8


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

Leitura Compatível Conflito

Escrita Conflito Conflito

Trincos de Leitura/Escrita


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)

9

Page 9


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

10

Page 10


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

11

Page 11


Solução optimista


Recuperação das falhas de paragem


12

Page 12


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

13

Page 13


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.

14

Page 14


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

15

Page 15


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.

16

Page 16



• 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

17

Page 17


Transacções distribuídas:

Modelo de Faltas

• Distribuição implica lidar com:– Falta dos discos

– Falta das máquinas

– 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)

Faltas de Paragem


Papel do Coordenador

..

BranchZ

BranchX

participant

participant

C

D

Client

BranchY

B

A

participantjoin

join

join

T

a.withdraw(4);

c.deposit(4);

b.withdraw(3);

d.deposit(3);

openTransaction

b.withdraw(T, 3);

closeTransaction

T = openTransaction

a.withdraw(4);

c.deposit(4);b.withdraw(3);d.deposit(3);

closeTransaction

Note: the coordinator is in one of the servers, e.g. BranchX

Só quando é chamado closeTransaction se executa o protocolo para confirmar ou abortar a transacção atomicamente

18

Page 18


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

19

Page 19


Protocolo (sem falhas)

canCommit?

Yes

doCommit

haveCommitted

Coordinator

1

3

(waiting for votes)

committed

done

prepared to commit

step

Participant

2

4

(uncertain)

prepared to commit

committed

statusstepstatus


Protocolo (sem falhas)CoordenadorEnvia PREPARAR a todos

if (todos votaram sim)decisãocoord = commitEnvia COMMIT a todos

elsedecisãocoord = abortEnvia ABORT a todos que votaram sim

exit

Participante i

Envia votoi ao coord.if (votoi == não)

decisãoi = abortexit

if (recebe ABORT)decisãoi = abort

elsedecisãoi = commit

exit

20

Page 20


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.

21

Page 21


Transacções distribuídas:2PC - diagramas de interacções

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

Pronto?

W diário

Envia mensagem

W diário

Envia mensagem

Espera

W diário

Envia mensagem

diário

Todas?

Termina transacção

W diário

Envia mensagem

Espera

W diárioEnvia mensagem

Todas?

Espera

diário

prepararbegincommit

end

Um Não?

W diárioEnvia mensagem

abort

Abortar?

Espera

W diário

abort

ready

abort

S

S

S

S

commit

commitS


Logs do protocolo

• Assume um diário (log) persistente com escritas atómica

Evento Info. escrita no log Instante da escrita

Coord. envia PREPARAR Begin commit Em paralelo com envio

Participante vota sim Sim Antes de enviar voto

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

22

Page 22


Diagrama de Estados - Coordenador

inicial

espera

abort commit

temporizador

expirou

Input: -

Output: Envia PREPARAR a todos

Input: Recebe SIM de todos

Output: Envia COMMIT a todos

Input: Recebe um ou mais NÃOOu temporizador expira

Output: Envia ABORT a todos

A detecção de faltas de

paragem é por timeout

coordenador pode logo tomar a

decisão de abortar ou tentar

contactar novamente os

participantes


Diagrama de Estado - Participante

inicial

Preparado

abort commit

Input: Recebe PREPARAR e votoi == simOutput: Envia sim ao coordenador

Input: Recebe COMMIT

Input: (Recebe PREPARARe votoi == não)

Ou temporizador expira

Output: Envia não ao coord.

Input: Recebe

ABORT

temporizador

expirou

Executar protocolo de

terminação

23

Page 23



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



Transacções distribuídas: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


24

Page 24


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)

25

Page 25


Arquitectura X/OpenTransacções distribuídas



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

26

Page 26


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

Aplicação

TM

RM

IniciarConfirmar

Abortar

LerEscrever

Associar

PrepararConfirmar

Abortar

27

Page 27



X/Open (com distribuição)

Aplicação

TM

RM

SC

TM

RM

SC



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

28

Page 28


TP-Monitor components (generic)

persistentqueue

Application

program

Recovery

manager

Log

manager

database

persistentqueue

data

dictionary

context

database

program

library

client

external

resource

manager

client

client

Pre

sen

tati

on

ser

vic

es

Au

then

tica

tion

Administration and operations interfaces

Monitor services

scheduling load balancing

server classqueues

contextbinding

internal

resource

managers

From “Transaction Processing” Gray&Reuter. Morgan Kaufmann 1993


Monitor Transaccional Tuxedo da BEA

Application Program (AP)

Transaction

Manager (TM)

TX API

XA

+

XA

XAP-TP

C-ISAM or SQL or

Other

Communication

Resource Manager

(CRM)

X/Open DTP Reference Model

OSI-TP

Tuxedo System in DTP Model

C, COBOL, 4GLs or CASE appllications

System /T

Communications

TX API

XA+

XA

XAP-TP

OSI-TP

Unix System V

System /T

XATMI or

CPI-C or

TxRPC or

Peer-toPeer

XATMI or

TxRPC

Resource

Manager (RM)

XA-Compliant

Resouce Manager

SQL

Documents

Transacções em Sistemas Distribuídosdisciplinas.ist.utl.pt/~leic-sod.daemon/2012-2013-sem2/teoricas... · associados aos objectos e tratar os problemas de interblocagem. • Gestor