Protocolos de Efetiva¸c˜ao

O protocolo de efetiva¸c˜ao ´e um mecanismo essencial na garantia da propriedade da atom- icidade de transa¸c˜oes que executam opera¸c˜oes em bases de dados distribu´ıdas. Ele visa garantir que ou todas as opera¸c˜oes sejam efetivadas (confirmadas como permanentes) ou todas as opera¸c˜oes sejam abortadas (desfeitas).

A execu¸c˜ao do protocolo de efetiva¸c˜ao ´e uma das fases da transa¸c˜ao que mais influen- ciam no seu desempenho. Isso ocorre porque s˜ao requeridos dois tipos de opera¸c˜oes con- sideradas de alto tempo de resposta: (i) opera¸c˜oes de comunica¸c˜ao remota – necess´arias para a comunica¸c˜ao entre o coordenador e os participantes; (ii) opera¸c˜oes de escrita em disco – necess´arias para o processo de logging realizado pelo protocolo.

O protocolo de efetiva¸c˜ao mais utilizado ´e o 2PC (two-phase commit8_{). Apesar do 2PC} ser um protocolo considerado eficaz na garantia da atomicidade de transa¸c˜oes distribu´ıdas, ele ´e considerado um protocolo de baixo desempenho. Para superar essa limita¸c˜ao, v´arias otimiza¸c˜oes do 2PC tˆem sido propostas. Os protocolos PrC e PrA est˜ao entre as suas otimiza¸c˜oes mais comuns [2].

O protocolo 2PC e seus variantes s˜ao projetados para executar em um ambiente dis- tribu´ıdo composto por um coordenador e v´arios participantes. O coordenador ´e o ponto onde a aplica¸c˜ao transacional est´a localizada e os participantes s˜ao os pontos distribu´ıdos onde est˜ao localizadas as bases de dados acessadas pela aplica¸c˜ao.

Para garantir a tolerˆancia `as falhas ocorridas no momento da execu¸c˜ao, o progresso do protocolo normalmente ´e armazenado em logs mantidos tanto pelo coordenador quanto pelos participantes. As opera¸c˜oes de escrita nesses logs podem ser de dois tipos: force ou non-force. Opera¸c˜oes do tipo force s˜ao escritas imediatamente no log, o que gera um acesso a disco. Opera¸c˜oes do tipo non-force s´o s˜ao escritas no log eventualmente. Apesar de demandarem menos acesso a disco, escritas do tipo non-force ficam vulner´aveis a perdas at´e que elas sejam escritas em disco [95].

As se¸c˜oes a seguir apresentam uma breve introdu¸c˜ao do protocolo 2PC e dos variantes 2PrC e 2PrA.

Two Phase Commit (2PC)

Como o seu nome sugere, o protocolo 2PC ´e composto por duas fases: a fase de vota¸c˜ao e a fase de decis˜ao. Na fase de vota¸c˜ao, o coordenador envia um pedido de voto (prepare) para cada um dos participantes envolvidos. Como resposta, cada participante pode decidir se a transa¸c˜ao deve ser efetivada ou cancelada. Depois de recebidos todos os votos, o protocolo passa para a fase de decis˜ao. Se todos os participantes concordarem em efetivar a transa¸c˜ao, o coordenador envia a decis˜ao de efetiva¸c˜ao para os participantes. Se ao

8

menos um participante votar para abortar a transa¸c˜ao, o coordenador envia a decis˜ao de cancelamento para os participantes. Ao receber a decis˜ao cada participante responde ao coordenador com uma mensagem acknowledge9_.

No protocolo 2PC, o coordenador realiza uma escrita ao log do tipo force e uma do tipo non-force – a primeira para registrar a decis˜ao e a segunda para registrar o fim da execu¸c˜ao do protocolo. Al´em disso, cada participante realiza duas escritas ao log do tipo

non-force – para registrar o seu voto e a decis˜ao do coordenador.

Presumed Commit (PrC)

O protocolo PrC ´e uma otimiza¸c˜ao do protocolo 2PC que reduz o custo de transa¸c˜oes efetivadas. O PrC interpreta a falta de informa¸c˜ao como uma decis˜ao de efetiva¸c˜ao. Para isso, o coordenador escreve um registro de inicializa¸c˜ao do tipo force antes de enviar o pedido de voto (prepare) aos participantes. Quando o coordenador decide efetivar a transa¸c˜ao, ele escreve um registro de efetiva¸c˜ao do tipo force e, em seguida, envia a decis˜ao aos participantes. Cada participante registra como non-force a decis˜ao de efetiva¸c˜ao e libera os recursos transacionais sem enviar mensagem de acknowledge ao coordenador.

No protocolo PrC, o caso de cancelamento (abort) ´e tratado de maneira diferente. Quando o coordenador decide cancelar uma transa¸c˜ao, ele envia a decis˜ao de cancela- mento para os participantes e espera pelas mensagens de acknowledge. Essa decis˜ao n˜ao ´e registrada pelo coordenador. Cada participante escreve como force a decis˜ao de cance- lamento e envia a mensagem de acknowledge ao coordenador. Ao receber as mensagens de acknowledge, o coordenador registra como non-force o fim do protocolo.

Em compara¸c˜ao ao 2PC, o PrC economiza uma mensagem de acknowledge de cada participante e uma escrita ao log do tipo force para o caso de efetiva¸c˜ao. Em contrapartida, o PrC inclui uma escrita extra do tipo force no coordenador para registrar a in´ıcio do protocolo. No total, o custo de efetivar uma transa¸c˜ao com o PrC ´e de 2 + p escritas do tipo force e de 3p mensagens10_.

Presumed Abort (PrA)

O protocolo PrA ´e uma otimiza¸c˜ao do PrC que, ao contr´ario do PrC, reduz o custo de transa¸c˜oes abortadas. No PrA, quando o coordenador decide abortar uma transa¸c˜ao, ele envia mensagens de cancelamento para todos os participantes sem gravar a decis˜ao no log. Cada participante escreve como non-force um registro de cancelamento sem a necessidade de enviar mensagem de acknowledge ao coordenador. No caso de efetiva¸c˜ao, o PrA funciona da mesma forma que o 2PC.

9

Mensagem onde o participante confirma estar ciente da decis˜ao. 10

100 Cap´ıtulo 6. Servi¸cos de Transa¸c˜oes Abertos

Em compara¸c˜ao ao 2PC, o PrA economiza uma escrita do tipo force no coordenador e em cada participante, al´em de economizar uma mensagem de acknowledge em cada participante no caso de abort. No total, o custo para se cancelar uma transa¸c˜ao no PrA ´e de 3p mensagens e de p escritas do tipo force. O custo de efetivar uma transa¸c˜ao no PrA ´e o mesmo do 2PC.