tecnologia de sistemas distribuídos capítulo 7:...

1

Tecnologia de Sistemas Distribuídos7. Transacções

1

Tecnologia de SistemasDistribuídos

Capítulo 7: Transacções

Paulo FerreiraPaulo. [email protected]

Alves [email protected]

INESC/IST


2

Objectivos• garantir que aplicações que manipulam estruturas de dados

persistentes têm: – possibilidade de recuperar de estados errados,– sincronizam as suas acções de forma consistente com outras transacções que

utilizam os mesmos dados

• transferir uma dada quantia entre duas contas em dois bancosdistintos (A e B):

transferencia (bancoA, bancoB, Valor){ LerSaldo (bancoA, SaldoA); /*obtendo 200.000$00*/ LerSaldo (bancoB, SaldoB); /*obtendo 200.000$00 */

Depositar(bancoA, saldoA-Valor); Depositar(bancoB, saldoB+Valor);}

• paragem do sistema do Banco B, depois de executar a primeiraescrita, mas antes da segunda ter sido iniciada?

2


3

Propriedades• Atomicidade - uma transacção ou se executa na totalidade ou não

se executa.• Consistência - cada transacção deve, a partir de um estado inicial

válido e caso se execute completamente, atingir um novo estadoválido

• Seriabilidade (Isolation) - se diversas transacções se executaremem paralelo sobre os mesmos objectos, o resultado é como seas transacções se executassem em série numa determinadaordem

• Persistência (Durability) - os resultados de uma transacção queconfirmou permanecem depois desta acabar e são supostossobreviver ao conjunto de faltas expectáveis dos mecanismos dearmazenamento.


4

Tipos de Transacções• Localização - dados sobre os quais a transacção se

realiza estão todos no mesmo local físico ou repartidospor vários sistemas

• Duração - transacções destinadas a actualizaçõesinteractivas (on-line) e aquelas que irão ser executadassobre grandes volumes de informação, de forma nãointeractiva (off-line)

• Estrutura - a uma transacção apenas poder corresponderum único fio de execução ou existirem múltiplos fluxos deexecução no interior de uma transacção

3


5

Tipologia das Faltas• Aborto explícito da transacção.

– explicitamente desencadeada pelo programa

• Falta de paragem do sistema:– perdeu-se o conteúdo da memória volátil

• Falta nos sistemas de armazenamento persistente:– é necessário implementar uma memória estável que garanta a

redundância da informação e que permita recuperar a que tenha sidoeventualmente destruída.

• Falta na comunicação:– normalmente considera-se que são faltas temporárias e que é possível

recuperá-las, repetindo as mensagens– partição física da rede, resultante de uma máquina, encaminhador ou

linha falharem e isolarem duas partes da rede


6

Sincronização• necessidade de sincronização das operações de leitura e

escrita deriva da propriedade de isolamento• é necessário controlar a forma como os valores das

variáveis são vistas de outras transacções, pois estas nãopoderão aceder a valores parciais, uma vez que atransacção pode ainda abortar

• a sincronização do acesso a variáveis partilhas é oproblema clássico de sincronização dos leitores/escritores

• a execução de um conjunto de transacções pode serdescrita através de uma história que explicite a ordemrelativa de execução das operações das transacções

4


7

Seriabilidade• uma história é serializada se, para qualquer duas transacções T i e T j,

todas as operações de T i aparecerem antes de todas as operaçõesde Tj ou vice-versa

• não se pretende uma execução realmente em série• o objectivo é garantir que as histórias são serializáveis, mas que a

sincronização só impede a progressão de uma transacção se forestritamente necessário

• antes de utilizar qualquer objecto, a transacção requisita um trinco deleitura ou escrita consoante o acesso que pretende efectuar

• múltiplos acessos em leitura são permitidos, mas um acesso emescrita bloqueará todos os acessos subsequentes

• se uma transacção detiver um trinco de leitura sobre um dado registo,não será permitida a outra obter um trinco de escrita

• a transacção que o pretenda fazer ficará bloqueada até que todos ostrincos de leitura sejam libertados


8

Sincronização em Duas Fases• primeira fase:

– começa por adquirir sucessivamente os trincos que lhe permitem acederaos objectos (fase de crescimento)

• segunda fase:– liberta os trincos (fase de decrescimento)

• problema:– determinar o ponto em que mais nenhum trinco será necessário– se uma transacção libertasse um trinco, poderia revelar o valor de um

registo que seria utilizado por uma transacção concorrente– caso a transacção inicial pretendesse voltar a utilizar o registo, já não

poderia ser assegurada a serialização da execução– uma transacção deveria apenas libertar um trinco quando tivesse a

certeza que não iria requisitar mais nenhum trinco

5


9

Sincronização em Duas Fases Estrita• strict two-phase locking:

– a fase de libertação dos trincos apenas ocorre quando a transacçãotermina

– pode obrigar uma transacção a esperar por transacções demoradasapenas porque se iniciaram antes

• há sistemas que permitem libertar alguns dos trincosantes de terminar a transacção:

– porque se a transacção vier posteriormente a abortar, é necessárioabortar as transacções que entretanto tenham utilizado os resultados

• visão pessimista:– pressupõe que os conflitos são frequentes e obriga à prévia

sincronização de todos os acessos

• visão optimista:– os conflitos são raros e, portanto, as transacções podem-se executar

mais rapidamente sem sincronização


10

Aproximação Optimista• em vez de efectuar a sincronização antes de aceder aos

objectos:– executam-se as operações sem sincronização– verifica-se se houve conflitos na confirmação– se existirem conflitos, aborta-se a transacção– utilização de marcas temporais associadas às operações sobre os

objectos para ordenação das transacções– eficácia em situações de carga tende a ser pior do que numa gestão

pessimista– não são geralmente utilizados em sistemas comerciais

6


11

Interblocagem• a sincronização baseada em trincos ou semáforos conduz

à possibilidade de interblocagem• a probabilidade de uma situação de interblocagem é

reduzida• as suas consequências são graves, porque param uma

ou várias aplicações• tratamento da interblocagem:

– evitar que a interblocagem apareça– detectá-las e recuperar da situação


12

Interblocagem (cont.)• prevenção - conjunto de regras a que deve obedecer a

escrita das transacções, ou a forma como sãoexecutadas:

– estabelecer uma ordem para as operações de sincronização sobre ostrincos

– obrigar a efectuar a requisição de todos os trincos no início da transacçãoe só a deixar prosseguir se os tiver obtido

• detecção e solução:– usar um temporizador que, quando expira, assinala que a transacção

está possivelmente bloqueada– solução pouco precisa, porque a transacção pode ter sido retardada por

outras condições de execução– método simples e tendo em consideração a frequência rara de

interblocagem, é normalmente considerado adequado– a forma mais simples de recuperação é abortar a transacção

7


13

Subtransacções Encaixadas• lançar subtransacções que executam em paralelo operações locais

ou distribuídas• em vez de uma estrutura linear ou uniforme ( flat) da transacção, esta

passa a ser constituída como uma árvore de transacções, com origemnuma transacção raiz (top-level) que lançará subtransacções

• as subtransacções podem, por sua vez, dar origem a outrassubtransacções que designaremos por encaixadas (nestedtransactions)

• permite controlar o grau de atomicidade que se pretende naaplicação:

– numa operação complexa, não se pretende eliminar todo o processamentoefectuado quando aparece uma falta

– manter o que já foi efectuado consistentemente e escolher outra alternativa para acontinuação da operação

– tratando o resultado de cada subtransacção, pode-se manter a atomicidade global,evitando o desfazer das partes consistentes da actualização da base de dados


14

Subtransacções Encaixadas (cont.)• a existência de subtransacções tem de ser coerente com

o modelo geral, em particular com as propriedades ACID

• quando uma subtransacção confirmar, os seus resultados não podemainda ser tornados visíveis, pois a ou as transacções suasantecedentes ainda podem abortar

• a confirmação de uma subtransacção apenas torna os seus dadosvisíveis à transacção antecessora

• só quando a transacção raiz confirmar é que os dados se podemtornar persistentes

• as modificações produzidas pelas subtransacções são ignoradas se atransacção raiz abortar

• a propriedade de Persistência não é válida a nível das subtransações,apenas se verificando quando a transacção raiz confirmar

8


15

Subtransacções Encaixadas (cont.)• sincronização:

• uma subtransacção pode obter trincos que eram possuídos pela sua ascendente;

• quando uma transacção confirma todos os seus trincos, incluindo aqueles queforam herdados, são retomados pela sua ascendente;

• se uma falta ocorrer e a subtransacção abortar, todos os trincos que foramadquiridos são perdidos ou retomados pela sua ascendente e o ascendente éinformado; o ascendente pode escolher entre continuar o processamento ou elepróprio abortar.

• poucos sistemas comerciais exploraram aspotencialidades das transacções encaixadas


16

Arquitectura• máquina virtual que garanta as propriedades das

transacções: Sistema Transaccional

Aplicações

Sistema Transaccional

Iniciar Confirmar Abortar

LerEscrever

Sistema Operativo

Hardware

Aplicações

9


17

Arquitectura• sistema transaccional é composto:

– gestor de escalonamento» é responsável pela sincronização de todos os acessos aos dados

manipulados pelas transacções» deve 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– gestor do diário - gere uma lista que regista as operações relevantes de

actualização da estrutura de dados– gestor da recuperação

» recuperar o sistema para um estado consistente sempre que uma falta fordetectada

» a gestão da cache, a informação escrita no diário e o algoritmo derecuperação estão intimamente relacionados

– gestor de memória estável» garante a persistência dos dados» fornecer uma abstracção de memória estável, ou seja, uma memória

persistente, capaz de manter a informação mesmo quando existem falhas dosdiscos


18

Gestor da Cache• gere a relação entre os discos e a memória volátil• objectivo:

– evitar tanto quanto possível executar escritas síncronas, agrupandoescritas em bloco para o disco

– princípio da localidade das referências permite esperar que as leiturassejam consideravelmente optimizadas se uma parte significativa dosdados permanecer em memória volátil

• implica:– controlar um conjunto de tampões de dimensão idêntica aos blocos de

disco, onde realmente se efectuam as operações de leitura/escrita dosdados

– implementação da política de substituição (ex.: FIFO, LRU)– analogia entre os objectivos de cache do sistema transaccional e aquela

que é habitual no sistema de ficheiros– especificidades que derivam do padrão diferente de acesso aos dados

nas transacções e nos sistemas de ficheiros tradicionais.

10


19

Gestor do Diário• falta de paragem:

– perde-se o conteúdo da memória volátil– é um problema de grande importância no sistema transaccional e que condiciona o

modo como o gestor da cache opera

• recuperação do estado da estrutura de dados modificada duranteuma transacção :

– é necessário dispor de informação redundante que possibilite a reposição de umestado correcto

• diário ( log):– mantem a informação mencionada acima numa lista que regista as operações

relevantes de actualização da estrutura de dados– ficheiro escrito sequencialmente, o que garante que a informação é registada

segundo a ordem de execução das operações– salvaguardado em memória estável, mas naturalmente a escrita efectua-se para

páginas na memória volátil que vão sendo escritas para o disco– protocolos de actualização do diário e de transferência de páginas da cache para o

disco garantam que existe sempre redundância da informação modificada pelastransacções em curso

– o diário e a base de dados sejam mantidos em discos diferentes para melhorar odesempenho e diminuir o risco de faltas simultâneas.


20

Interacção dos Gestores• transacção começa por uma chamada à função iniciar:

– atribuição de um identificador à transacção, preparação das estruturas dedados de suporte e registo no diário do início da transacção

• leitura:– verificar se a informação já está em cache; caso não esteja, tem de ser

lida do disco– se a informação está residente em memória volátil, deve ser efectuada a

sincronização adequada pelo gestor de escalonamento, antes dos dadosserem disponibilizados à aplicação

• escrita:– para além das operações anteriores, é necessário manter informação

redundante (no diário) para possibilitar a recuperação

• confirmar:– o resultado operações tem de ser tornado persistente, mesmo que

permaneça informação em cache e que sobrevenham faltas de paragem

11


21

Suporte à Atomicidade• para garantir a atomicidade na presença de faltas de paragem, torna-se

necessário recuperar a base de dados para o último estado consistente:– é necessário desfazer as modificações das transacções não confirmadas

– garantir que os dados das transacções confirmadas estão actualizados de forma consistente

• escritas são efectuadas:– sobre os dados reais residentes nos suportes magnéticos - actualização directa (in-place

updating)– são criadas novas versões dos dados, preservando os valores originais - actualização em

versões (out-place updating)

• actualização directa:– estruturas de dados são modificadas na memória volátil– quando as páginas são recopiadas para o disco vão substituir as páginas originais– os valores iniciais dos dados modificados são perdidos, o que implica que tem de ser mantida

informação no diário para repor os valores anteriores no caso de aborto da transacção

• actualização em versões:– a informação é copiada para outras páginas, pelo que implicitamente se garante a redundância

– é mais simples, porque a redundância fica assegurada pelo próprio mecanismo de manutençãodos dados originais

– a sua utilização é bastante mais reduzida nos sistemas, pela implícita sobrecarga de tempo deexecução e pela dispersão dos dados pelo disco


22

Actualização Directa• momento em que as modificações efectuadas na cache

são salvaguardadas na memória persistente?• salvaguarda dos dados na confirmação:

– forçar a salvaguarda da cache (cache flush) no momento em que atransacção é confirmada

– menos tempo de permanência da informação modificada na memóriavolátil

– acréscimo significativo de tempo na execução da confirmação

• salvaguarda dos dados assíncrona:– deixar a informação na cache até que, naturalmente, as páginas sejam

necessárias para dados de outras transacções ou seja oportuno efectuara transferência de blocos para o disco

– é necessário garantir que, pelo menos, o diário foi escritopersistentemente, para que a redundância possibilite refazer asoperações

12


23

Actualização Directa (cont.)• permitir ou não que dados de transacções activas (que

ainda não foram confirmadas ou abortadas) sejamescritos na memória persistente?

• se não for permitido:– as páginas modificadas de todas as transacções activas têm de

permanecer na memória volátil, com as consequentes implicações emtermos do espaço de memória utilizada

• se for permitido:– existe a possibilidade de se escreverem na memória persistente dados de

transacções que irão abortar– é necessário garantir que existe informação no diário para, neste caso,

desfazer as operações das transacções que abortem ou sejamconsideradas abortadas na sequência de uma falta


24

Gestão da Cache• quatro possibilidades:

– salvaguarda na confirmação e actualização na confirmação– salvaguarda na confirmação e actualização assíncrona– salvaguarda assíncrona e actualização na confirmação– salvaguarda assíncrona e actualização assíncrona

• quanto mais restritiva for a política de gestão da cache (operaçõessíncronas de actualização e salvaguarda):

– menos informação terá que ser mantida no diário– menos benefícios se obtêm da utilização da cache na redução do tempo de

execução das transacções

• salvaguarda forçada na confirmação:– informação persistente fica actualizada nesse momento– não será necessário manter no diário a informação para refazer (redo) as

operações

• actualizações diferidas até ao momento da confirmação:– elimina-se a necessidade de informação para desfazer (undo) as operações– a informação mantém-se volátil até que a transacção seja confirmada– implica que se construa uma nova versão em memória virtual

13


25

Gestão da Cache (cont.)• gestão mais eficiente:

– políticas assíncronas quer para a salvaguarda, quer para a actualização– é necessário que o diário contenha informação para refazer e desfazer

(redo/undo) as operações– particular atenção ao modo como as páginas dos objectos modificados

são salvaguardadas no disco– não se pode efectuar alterações na memória persistente se os registos no

diário relativos a essas páginas não foram ainda salvaguardados– escrita antecipada no diário (write-ahead log)– implementação mais usual dos sistemas transaccionais


26

Actualização em Versões• mantém inalterada a versão original do objecto enquanto a

transacção não confirmar• confirmação da transacção é uma operação crítica:

– tem de ser atómica a transição entre as versões do objecto– a recuperação é relativamente simples (basta descartar as novas versões das

transacções não confirmadas)

• ficheiros diferenciais:– um com a versão original e outro com a versão que está a ser actualizada– vector de bits para saber se um dado bloco está no ficheiro original ou na nova

versão– vector de bits é inicialmente colocado a zero– bit a um indica que o bloco em causa está na nova versão

• a informação modificada e a original têm de ser consolidadas quandoa transacção confirma:

– copiando as referências correspondentes aos blocos novos no descritor do ficheirooriginal

– a cópia tem a vantagem de ser idempotente (com auxílio de um diário pode-serecuperar de faltas de paragem durante a confirmação)

14


27

Actualização em Versões• shadow pages:

– procuram evitar a existência de dois ficheiros– durante a execução existe apenas uma descrição do ficheiro que

referencia as páginas da versão actual– na abertura do ficheiro, a tabela de páginas (estrutura que descreve as

páginas ou blocos do ficheiro) é copiada para outra localização no disco– quando uma página modificada é escrita no disco, será requisitado um

novo bloco– na tabela de páginas é indicado que o bloco foi modificado– quando a transacção confirma:

» a tabela de páginas e as páginas em cache têm de ser escritas parao disco antes de se mudar no directório a referência para a novatabela de páginas

» esta escrita tem de ser atómica, porque marca a alteração doficheiro (o nome passa a referenciar uma nova versão)

» caso a transacção aborte, é apenas necessário repor a tabela depáginas original que tinha sido salvaguardada

» pouco utilizada em SGBD comerciais (dimensão das tabelas depáginas e disseminação da informação pelo disco)


28

Gestão do Diário• falta de paragem do sistema:

– gestor da recuperação é chamado para colocar a base de dados numestado coerente

– diário é analisado:» transacções que não possuam registos de confirmação são

consideradas abortadas (operações de reposição do estado inicial)» as restantes transacções serão reexecutadas (operações sobre os

dados persistentes que constam dos registos de modificação)

• falta de paragem a meio da recuperação:– gestor de recuperação escreve no diário registos para indicar o início e o

fim da operação de recuperação– se houve uma interrupção do processo de recuperação, recomeça-lo-á a

partir do início, garantindo assim a sua atomicidade– pressupõe-se que as operações de modificação dos dados são

idempotentes

15


29

Gestão do Diário (cont.)• o registo do diário tem:

– campo que o identifica (LSN - Log Sequence Number)– identificador da transacção– marca temporal e índices para gerir listas ligadas dos registos

correspondentes a uma dada transacção– dados para refazer/desfazer dependem da natureza dos registos

actualizados

• formas de descrever as modificações no diário:– física– lógica


30

Modificações no Diário• registo físico:

– contem a imagem posterior (ou anterior e posterior) dos octetos queforam modificados

– velho valor/novo valor» valor antigo do objecto e o valor depois de modificado são guardados

no diário» operações de refazer e o desfazer são triviais» idempotência da operação de recuperação

– actualização dos dados é implícita pela respectiva posição na página

• registo lógico:– modificação descrita de forma operacional a partir de um reportório de

operações– descrição compacta que descreve como refazer e desfazer as alterações– mais económico em termos do espaço de disco utilizado– mais complexo de interpretar na recuperação– é necessário que a informação esteja situada nas páginas de forma

coerente com a operação

16


31

Salvaguarda do Diário• síncrona:

– a cada operação ter-se-á de adicionar o significativo incremento de tempopara efectuar a escrita no ficheiro

• assíncrona:– optimiza o desempenho das transacções, mas aumenta a incerteza sobre

a consistência da informação persistente

• em qualquer situação é crucial que:– a escrita de páginas de dados para a memória persistente se efectue

sempre depois da salvaguarda dos respectivos registos de modificaçãono ficheiro diário

• para aumentar a robustez às faltas dos discos:– o ficheiro do diário é normalmente duplicado (dois discos independentes)


32

Memória Estável• propriedade da persistência:

– implica que os dados de uma transacção que confirmou devem ser mantidos deforma durável

– tolerância a faltas do meio de armazenamento

• duas técnicas para implementação:– duplicação dos discos (mirroring)– salvaguarda da base de dados e replicação implícita da informação nos registos de

modificação do diário (archiving)

• mirroring:– o controlador de cada disco indicará se a operação decorreu normalmente– no caso negativo, a escrita do bloco deverá ser repetida– no caso positivo, pode-se assumir que a informação ficou correctamente gravada

nos dois discos– leitura efectua-se num dos discos e, caso o controlador não assinale um erro,

assume-se o bloco como bom– se existir um erro na leitura do primeiro disco, ir-se-á ler o segundo disco– assume-se que os dois discos falham independentemente e que são de falha

silenciosa

17


33

Memória Estável• operação de salvaguarda do diário deve também ser

atómica em relação a faltas:– escrita de uma marca de início de recuperação no diário– a base de dados é copiada e tornada consistente– não deixar mais transacções iniciarem-se e efectuar a limpeza da cache

para garantir que todas as alterações aos dados persistentes foramefectuadas

– outras alternativas permitem manter o sistema em execução (utilizandoposteriormente o diário para consolidar a informação modificadaenquanto a salvaguarda se efectuava)

– escrita do registo de fim de salvaguarda permite, na presença de falhas,saber se toda a operação se executou ou se ficou incompleta e, portanto,deve ser ignorada

– depois de uma operação de salvaguarda com sucesso, o sistema podeexaminar os registos de controlo do diário, determinando o ponto onde oficheiro deve ser truncado


34

Transacções Distribuídas• existem servidores que mantêm informação em múltiplas

máquinas• uma transacção consistirá na actualização de registos em

alguns deles• propriedades das transacções têm de se manter• o estado global é o conjunto dos dados persistentes

utilizados pela transacção nas diversas máquinas• distribuição implica:

– comunicação entre os sistemas– aparecimento de faltas devidas ao funcionamento das redes– mecanismo de RPC adequado permite uma grande parte das faltas de

comunicação– independência do padrão de faltas de paragem– transacção tem de terminar (confirmação ou aborto) de forma coerente

em todas as máquinas, sob pena de se perder a atomicidade– comunicação introduz atrasos que podem ser significativos na realização

de operações cruciais

18


35

Arquitectura Distribuída• consórcio X/OPEN:

– liderou um esforço de normalização dos protocolos e interfaces para interligaçãode sistemas de informação heterogéneos (DTP - Distributed TransactionProcessing)

– grandemente influenciada pela norma de facto que constituiu a arquitectura SNAda IBM e a sua interface LU 6.2

• X/Open:– gestores de recursos - RM (resource manager)

» armazenam os dados, garantindo localmente as propriedades dastransacções

– monitores transaccionais - TM (transaction managers)» pela coordenação dos RM, em particular pela execução dos protocolos de

inicialização e terminação das transacções– existe um gestor de transacção em cada nó ou em cada grupo de máquinas


36

X/Open

• aplicação inicia uma transacção:– invocando o TM local que lhe atribui um identificador único

• aplicação contacta em seguida com os RM:– para efectuar as operações de leitura e escrita (fornecendo como

parâmetro o identificador da transacção)

• quando RM recebe a primeira operação relacionada comuma transacção que ainda desconhecia:

– contacta o TM local para se associar a transacção

• quando a transacção termina:– todos os TM envolvidos executam o protocolo de consenso distribuído

19


37

X/Open (cont.)

Aplicação

TM

RM

AssociarPreparar Configurar Abortar

Iniciar Confirmar Abortar

Ler Escrever


38

X/Open (cont.)

Aplicação

TM

RM

SC

TM

SC RM

• maioria dos sistemas transaccionais distribuídos não apresentam ainda amodularidade e abertura do modelo X/Open

• evolução previsível para a interligação de sistemas heterogéneos:– a maioria dos sistemas de SGBD ofereçam interfaces com os protocolos normalizados,

permitindo a sua interligação a monitores transaccionais

20


39

Consenso Distribuído• confirmação em duas fases (two-phase commit ou 2PC):

– permite garantir que todos os nós envolvidos na transacção atingem oconsenso na decisão de Confirmar ou Abortar uma transacção

– é normalmente centralizado– o Coordenador, centraliza a comunicação com os restantes que

designaremos por Participantes– vamos considerar que:

» a falha por paragem do sistema é uma falha rápida» quando esta é detectada a máquina em causa pára e não responde

a mensagens que lhe são enviadas


40

Two-phase Commit• se não há falhas:

– Coordenador envia a todos os TM envolvidos uma mensagem parainiciarem o protocolo de confirmação (mensagem de Preparar)

– TM participantes assinalam aos RM locais que participam na transacção,que esta entrou na fase de preparação de confirmação

– RMs registam localmente este facto e indicam se a mesma decorreu deforma a garantir as propriedades locais de consistência

– em função das respostas, cada TM envolvido na transacção:» decide qual a mensagem (Confirmar ou Abortar) a enviar ao

Coordenador, e» escreve um registo no respectivo diário (registo de preparação) que

especifica qual a sua decisão sobre o estado de terminação datransacção

– os TM enviam uma mensagem ao Coordenador com a indicação doestado de terminação

– o Coordenador espera pela recepção das mensagens de todos os TMenvolvidos na transacção

21


41

Two-phase Commit (cont.)• se não há falhas (cont.):

– se todas as respostas forem afirmativas, o Coordenador considera que atransacção pode ser globalmente confirmada

– escreve o registo de confirmação no seu diário e envia uma mensagem(Confirmar Global) a todos os TM participantes

– TMs:» escrevem o registo de confirmação nos seus diários,» avisam os respectivos RMs,» e assinalam ao Coordenador que terminaram

– o Coordenador:» espera que todos os TM confirmem a terminação local da transacção» quando receber todas as mensagens de confirmação, considera que

finalmente a transacção terminou,» escreve esta informação no diário e retira a transacção do conjunto

de transacções activas» se algum dos TM indicar ao Coordenador que pretende abortar a

transacção, este decide que a transacção abortou e informa osrestantes nós, enviando uma mensagem de Abortar Global


42

Two-phase Commit (cont.)

Envia a mensagem para preparar

Escrever no Diário

Enviar Mensagem de Confirmação

Terminar Transacção

Escrever no Diário

Envia Mensagem

Escrever Confirmação no

Diário

Enviar Terminar

Participantes

Pronto para

Confirmar

Coordenador

Espera

Recebeu todas as

mensagens

Espera

Recebeu todas as

Terminações

Espera

Preparar

Confirmar

Confirmar Global

Ack

22


43

Two-phase Commit (cont.)

Inicial

Esperar

ConfirmarAbortar

Preparar

Coordenador Participante

Inicial

Preparado

ConfirmarAbortar

ConfirmarGlobal

AbortarGlobal

PrepararAbortar

AbortarGlobal

ConfirmarGlobal


44

Two-phase Commit (cont.)• expirar a temporização no Coordenador:

– no estado de Esperar, o Coordenador não pode decidir confirmar a transacçãounilateralmente

– pode pressupor que um, ou vários nós, não responderam por terem falhado e,portanto, considerar que a transacção deve ser abortada

– nos restantes estados, o Coordenador não pode tomar qualquer iniciativaautónoma, pelo que deverá repetir as mensagens até obter respostas dosParticipantes

• do lado dos Participantes:– só se não receber a mensagem de Preparar inicial poderá um TM participante, ao

fim de um determinado número de tentativas de contactar o Coordenador,considerar que a transacção abortou

– se o participante está no estado Preparado não pode progredir no algoritmo(depende da decisão do Coordenador que já influenciou)

– a transacção ficará activa e bloqueada até que o coordenador indique qual adecisão

– se os Participantes conseguirem comunicar entre si, é possível tentar resolver asituação:

» executando um protocolo de terminação que tente determinar qual a situaçãofinal da transacção junto dos outros Participantes

» se o único nó em falha é o do Coordenador, existem protocolos para elegerum novo Coordenador

23


45

Two-phase Commit (cont.)• falha de um TM participante:

– se a falha ocorrer no estado Inicial, o participante pode sem risco abortar atransacção

– se a falha ocorrer no estado de Preparado, o TM tem de recuperar, pois já afectoua conclusão do Coordenador e não pode tomar nenhuma acção unilateral

– gestor de recuperação encontra um registo de preparação:» contacta o Coordenador da transacção distribuída para se informar de qual foi

o respectivo estado de terminação» implica que o Coordenador, na fase final do protocolo, mantenha a

transacção activa, até que todos os nós confirmem a terminação datransacção

• falha do Coordenador:– se estiver no estado de Esperar, deve na recuperação reiniciar o protocolo,

inquirindo os Participantes sobre a resposta à mensagem de Preparar– se estiver no estado de Confirmar ou Abortar:

» o Coordenador não sabe se todos os Participantes já efectivamenteterminaram,

» deve repetir a mensagem global (Abortar ou Confirmar Global) e esperarpelas confirmações

• o protocolo é bloqueante, obrigando os Participantes a esperar pelarecuperação do Coordenador e este pela dos Participantes


46

Three-phase Commit• 2PC:

– só existem protocolos não bloqueantes quando a comunicação é fiável– os protocolos não bloqueantes envolvem maior número de mensagens e

são mais complexos

• 3PC:– introduz mais um estado: Pré-confirmação– entre o estado de Esperar e de Confirmação no Coordenador, e– entre o estado de Preparado e Confirmou nos Participantes– estado de Pré-confirmação:

» o TM está pronto a Confirmar, se esta for a decisão final,» mas ainda não confirmou,» só o fazendo quando recebe a mensagem de Confirmar Global» permite uma evolução do protocolo de terminação quando expira

uma temporização

24


47

Three-phase Commit (cont.)

Inicial

Esperar

Pré--Confirmação

Confirmar

Abortar

Confirmar Global

Preparar ConfirmaçãoAbortar

Preparar

Coordenador


48

Three-phase Commit (cont.)• estado de Pré-confirmação no 3PC:

– no Coordenador, o tratamento é o mesmo para os estados Inicial e deEsperar que já não eram bloqueantes

– no estado de Pré-confirmação, se a temporização expirar, o Coordenadornão sabe se os Participantes passaram para o estado de Pré-confirmação, mas

– sabe que pelo menos estavam no estado de Preparado, porque oprotocolo evolui sincronamente

– o Coordenador não fica bloqueado, podendo enviar um Confirmar Global,porque sabe que nenhum participante está no estado de Abortar (ele nãopoderia ter atingido o estado de Pré-confirmação)

– se a temporização aparecer no estado de Confirmação:» os Participantes podem não ter acabado a transacção, mas» estão pelo menos no estado de Pré-confirmaçã,» pelo que o Coordenador não precisa de efectuar nenhuma acção

especial

tecnologia de sistemas distribuídos capítulo 7:...

Documents