Confirmação Atómica não-Bloqueante Definição do Problema Garantir que todos os participantes correctos de uma transacção tomem a mesma decisão, nomeadamente,

Apresentação em tema: "Confirmação Atómica não-Bloqueante Definição do Problema Garantir que todos os participantes correctos de uma transacção tomem a mesma decisão, nomeadamente,"— Transcrição da apresentação:

1 Confirmação Atómica não-Bloqueante Definição do Problema Garantir que todos os participantes correctos de uma transacção tomem a mesma decisão, nomeadamente, confirmar ou abortar a transacção.

2 Confirmação Atómica não-Bloqueante Protocolo NBAC depende dos votos dos participantes e das falhas dos mesmos Requisitos do protocolo –Terminação; –Integridade; –Acordo Uniforme; –Validade; –Não-Trivialidade.

3 Não-Trivialidade Para solucionar cenários de falha. Decisão independente dos votos e do cenário de falha. –S-Não-Trivialidade - Se todos votam YES e não existem falhas, então o resultado é Commit; –AS-Não-Trivialidade - Se todos votam YES e não existem suspeitas de falhas, então o resultado é Commit.

4 Protocolo Genérico Procedure nbac(voto, participantes) begin (1.1) multicast_2(voto, participantes); (2.1) espera ((entrega de um voto NO de um participante) (2.2) ou (existe participante q: excepção(q) foi notificada a p) (2.3) ou (de cada participante q: entrega de um voto YES) (2.4) ); (3.1) caso (3.2) receba um voto NO -> resultado := propõe(Abort) (3.3) notificação de excepção -> resultado := propõe(Commit) (3.4) todos os votos YES -> resultado := propõe(Commit) (3.5) fim caso end

5 Sistemas Assíncronos Multicast_1 => AS_Rel_Multicast Multicast_2 => Multisend Excepção => Suspeita de falha Propõe(x) => Unif_Cons(x)

6 Protocolo Genérico Procedure AS_nbac(voto, participantes) begin (1.1) Multisend(voto, participantes); (2.1) espera ((entrega de um voto NO de um participante) (2.2) ou (existe participante q: suspeita(q)) (2.3) ou (de cada participante q: entrega de um voto YES) (2.4) ); (3.1) caso (3.2) receba um voto NO -> resultado := Unif_Cons(Abort) (3.3) notificação de excepção -> resultado := Unif_Cons(Commit) (3.4) todos os votos YES -> resultado := Unif_Cons(Commit) (3.5) fim caso end

7 Porque é que funciona? Integridade: por 3.2 e 3.4, se o sub-protocolo Unif_Cons satisfizer a propriedade; Validade: resulta da linha 3.4. Se todos votarem YES, o output de Unif_Cons será Commit; Acordo Uniforme: resulta da propriedade Acordo Uniforme do sub-protocolo Unif_Cons; AS-Não-Trivialidade: pela Completude do detector de falhas, pelo Acordo Uniforme e Validade de Unif_Cons, segue-se que a decisão será Commit;

8 Porque é que funciona? Terminação: depende da Completude dos detectores de falhas. Assuma-se que estes satisfazem a propriedade Completude Forte (i.e., a falha de um participante será suspeitada por todos os correctos). Assuma-se também uma rede fiável. Então p recebe um voto de q ou suspeita dele. Então o comando espera (2.1 a 2.4) termina para cada participante correcto. Pela propriedade de Terminação de Unif_Cons, todos os participantes correctos irão decidir.

9 Sistemas Assíncronos Multicast_1 => Multisend Multicast_2 => S_Rel_Multicast Excepção => Por timeout Propõe(x) => x

10 Protocolo Genérico Procedure S_nbac(voto, participantes) begin (1.1) S_Rel_Multicast(voto, participantes); (2.0) coloca timer a δ + Δ; (2.1) espera ((entrega de um voto NO de um participante) (2.2) ou (timeout) (2.3) ou (de cada participante q: entrega de um voto YES) (2.4) ); (3.1) caso (3.2) receba um voto NO -> resultado := Abort (3.3) timeout -> resultado := Commit (3.4) todos os votos YES -> resultado := Commit (3.5) fim caso end

11 Porque é que funciona? Terminação: ninguém espera mais que δ + Δ; Integridade: resulta da estrutura do protocolo; Validade: resulta de linha 3.4; S-Não-Trivialidade: Se não existirem falhas todos votam. Cada participante recebe os votos antes do seu timer expirar. Se os votos são todos YES então Commit;

12 Porque é que funciona? Acordo Uniforme: por absurdo, se p decide Commit e q Abort então por 3.4, p recebeu YES de todos e q decidiu em 3.2 ou 3.3. Em 3.2 é impossível porque todos enviam o mesmo voto para p e q (YES). Por 3.3 o timer de q (δ + Δ) expirou, por não receber o voto de r. Mas, no pior caso, r recebeu trans δ após q receber. Como p recebeu YES de r, pela propriedade de acordo uniforme da primitiva S_Rel_Multicast usada por r ao enviar o seu voto e pelo limite Δ associado a essa primitiva, segue-se que q recebeu o voto de r antes do seu timer expirar. Contradição.

13 Optimizações Se p recebe um voto NO de q pode decidir abortar imediatamente. Para Unif_Cons terminar p terá que propor um valor (Abort). No entanto, não terá que esperar pelo output pois já decidiu Abort. Pode também disseminar a decisão de Abort aos outros participantes através da primitiva AS_Rel_Multicast.