1
Page 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
Tecnologia de Sistemas Distribuídos7. Transacções
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
Page 2
Tecnologia de Sistemas Distribuídos7. Transacções
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.
Tecnologia de Sistemas Distribuídos7. Transacções
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
Page 3
Tecnologia de Sistemas Distribuídos7. Transacções
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
Tecnologia de Sistemas Distribuídos7. Transacções
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
Page 4
Tecnologia de Sistemas Distribuídos7. Transacções
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
Tecnologia de Sistemas Distribuídos7. Transacções
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
Page 5
Tecnologia de Sistemas Distribuídos7. Transacções
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
Tecnologia de Sistemas Distribuídos7. Transacções
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
Page 6
Tecnologia de Sistemas Distribuídos7. Transacções
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
Tecnologia de Sistemas Distribuídos7. Transacções
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
Page 7
Tecnologia de Sistemas Distribuídos7. Transacções
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
Tecnologia de Sistemas Distribuídos7. Transacções
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
Page 8
Tecnologia de Sistemas Distribuídos7. Transacções
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
Tecnologia de Sistemas Distribuídos7. Transacções
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
Page 9
Tecnologia de Sistemas Distribuídos7. Transacções
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
Tecnologia de Sistemas Distribuídos7. Transacções
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
Page 10
Tecnologia de Sistemas Distribuídos7. Transacções
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.
Tecnologia de Sistemas Distribuídos7. Transacções
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
Page 11
Tecnologia de Sistemas Distribuídos7. Transacções
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
Tecnologia de Sistemas Distribuídos7. Transacções
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
Page 12
Tecnologia de Sistemas Distribuídos7. Transacções
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
Tecnologia de Sistemas Distribuídos7. Transacções
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
Page 13
Tecnologia de Sistemas Distribuídos7. Transacções
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
Tecnologia de Sistemas Distribuídos7. Transacções
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
Page 14
Tecnologia de Sistemas Distribuídos7. Transacções
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)
Tecnologia de Sistemas Distribuídos7. Transacções
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
Page 15
Tecnologia de Sistemas Distribuídos7. Transacções
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
Tecnologia de Sistemas Distribuídos7. Transacções
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
Page 16
Tecnologia de Sistemas Distribuídos7. Transacções
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)
Tecnologia de Sistemas Distribuídos7. Transacções
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
Page 17
Tecnologia de Sistemas Distribuídos7. Transacções
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
Tecnologia de Sistemas Distribuídos7. Transacções
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
Page 18
Tecnologia de Sistemas Distribuídos7. Transacções
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
Tecnologia de Sistemas Distribuídos7. Transacções
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
Page 19
Tecnologia de Sistemas Distribuídos7. Transacções
37
X/Open (cont.)
Aplicação
TM
RM
AssociarPreparar Configurar Abortar
Iniciar Confirmar Abortar
Ler Escrever
Tecnologia de Sistemas Distribuídos7. Transacções
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
Page 20
Tecnologia de Sistemas Distribuídos7. Transacções
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
Tecnologia de Sistemas Distribuídos7. Transacções
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
Page 21
Tecnologia de Sistemas Distribuídos7. Transacções
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
Tecnologia de Sistemas Distribuídos7. Transacções
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
Page 22
Tecnologia de Sistemas Distribuídos7. Transacções
43
Two-phase Commit (cont.)
Inicial
Esperar
ConfirmarAbortar
Preparar
Coordenador Participante
Inicial
Preparado
ConfirmarAbortar
ConfirmarGlobal
AbortarGlobal
PrepararAbortar
AbortarGlobal
ConfirmarGlobal
Tecnologia de Sistemas Distribuídos7. Transacções
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
Page 23
Tecnologia de Sistemas Distribuídos7. Transacções
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
Tecnologia de Sistemas Distribuídos7. Transacções
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
Page 24
Tecnologia de Sistemas Distribuídos7. Transacções
47
Three-phase Commit (cont.)
Inicial
Esperar
Pré--Confirmação
Confirmar
Abortar
Confirmar Global
Preparar ConfirmaçãoAbortar
Preparar
Coordenador
Tecnologia de Sistemas Distribuídos7. Transacções
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
Top Related