Os protocolos definidos por WS-AtomicTransaction

Os seguintes protocolos de coordena¸c˜ao s˜ao definidos por WS-AtomicTransaction: comple- tion e 2PC, sendo que este ´ultimo apresenta duas varia¸c˜oes: 2PC dur´avel e 2PC vol´atil. Vamos analisar cada um desses protocolos a seguir.

O protocolo completion

O protocolo completion ´e utilizado para encerrar (isto ´e, efetivar ou abortar) uma transa¸c˜ao. Assim como os servi¸cos de ativa¸c˜ao e registro de WS-Coordination, este protocolo tamb´em define dois pap´eis: o coordenador, para quem os participantes solicitam o encerramento de uma transa¸c˜ao, e o participante (tamb´em denominado cliente ou iniciador), que ´e quem solicita o encerramento da transa¸c˜ao. WS-AtomicTransaction define um port type para cada um desses pap´eis, denom- inados CompletionCoordinatorPortType e CompletionInitiatorPortType. O primeiro possui duas opera¸c˜oes: Commit e Rollback, e deve ser implementado pelo coordenador. O segundo possui tamb´em duas opera¸c˜oes: Committed e Aborted, mas deve ser implementado pelo participante. O participante precisa implementar o port type CompletionInitiatorPortType para poder receber a resposta ass´ıncrona do coordenador.

O protocolo completion ´e utilizado por um participante do seguinte modo: primeiramente, o participante envia ao coordenador uma mensagem Commit ou uma mensagem Rollback. A mensagem enviada determina se o coordenador ir´a tentar efetivar a transa¸c˜ao ou se ele ir´a abort´a- la. Ap´os receber uma dessas mensagens, o coordenador tomar´a as providˆencias para encerrar a transa¸c˜ao. Tais providˆencias tipicamente incluir˜ao a execu¸c˜ao de algum outro protocolo, como por exemplo o 2PC. Depois de encerrar a transa¸c˜ao, o coordenador devolve ao participante uma men- sagem Committed ou Aborted, indicando se a transa¸c˜ao foi efetivada ou abortada. ´E importante ressaltar que as providˆencias tomadas pelo coordenador para encerrar a transa¸c˜ao s˜ao irrelevantes para o participante. Este ´ultimo est´a interessado apenas no desfecho da transa¸c˜ao, e n˜ao no modo como tal desfecho ´e alcan¸cado. A figura 12 ilustra as mensagens envolvidas no protocolo completion.

Figura 12: As mensagens envolvidas no protocolo completion.

O protocolo de efetiva¸c˜ao em duas fases (2PC) define um mecanismo para que m´ultiplos participantes cheguem a um consenso sobre o resultado de uma transa¸c˜ao. Assim como o proto- colo completion, o 2PC tamb´em define dois pap´eis: o coordenador, respons´avel por decidir se a transa¸c˜ao distribu´ıda deve ser efetivada ou abortada, e o participante, que representa um recurso transacional. WS-AtomicTransaction define um port type para cada um desses pap´eis, denomina- dos CoordinatorPortType e ParticipantPortType. O primeiro possui cinco opera¸c˜oes: Prepared, Aborted, ReadOnly, Committed e Replay, e deve ser implementado pelo coordenador. J´a o segundo possui trˆes opera¸c˜oes: Prepare, Commit e Rollback, e deve ser implementado pelo participante.

Conforme vimos anteriormente, o 2PC ´e um protocolo executado em duas fases11

:

1. Fase de vota¸c˜ao: o coordenador inicia a efetiva¸c˜ao de uma transa¸c˜ao atˆomica distribu´ıda e en- via mensagens Prepare ao ParticipantPortType de cada um dos participantes que se regis- traram para o protocolo 2PC. Tais participantes devem ent˜ao responder ao CoordinatorPort- Typedo coordenador com uma destas mensagens:

• Prepared: indicando que o participante tornou dur´aveis, por´em de modo n˜ao definitivo, quaisquer altera¸c˜oes sob sua responsabilidade, e que ele vota sim para a efetiva¸c˜ao da transa¸c˜ao distribu´ıda;

• ReadOnly: indicando que o participante vota sim para a efetiva¸c˜ao da transa¸c˜ao dis- tribu´ıda e que ele n˜ao deseja participar da segunda etapa do 2PC;

• Aborted: indicando que o participante abortou a sua subtransa¸c˜ao e portanto vota n˜ao para a efetiva¸c˜ao da transa¸c˜ao distribu´ıda.

2. Fase de efetiva¸c˜ao: o coordenador faz a apura¸c˜ao dos votos. Se todos os participantes re- sponderam com mensagens Prepared ou ReadOnly, ent˜ao a transa¸c˜ao ser´a efetivada, caso

11

contr´ario ela ser´a abortada. No caso de uma decis˜ao pela efetiva¸c˜ao da transa¸c˜ao, o coor- denador envia uma mensagem Commit para o ParticipantPortType dos participantes que responderam com a mensagem Prepared na primeira fase do protocolo. Cada um desses participantes deve responder ao CoordinatorPortType do coordenador com uma mensagem Committed, indicando que a sua subtransa¸c˜ao foi efetivada. No caso de uma decis˜ao por abor- tar a transa¸c˜ao, o coordenador envia uma mensagem Rollback para o ParticipantPortType dos participantes que responderam com a mensagem Prepared na primeira fase do protocolo. Tais participantes ent˜ao respondem ao CoordinatorPortType do coordenador com a men- sagem Aborted, indicando que eles abortaram suas subtransa¸c˜oes.

As figuras 13, 14 e 15 ilustram alguns cen´arios do protocolo 2PC.

Figura 13: O participante responde Prepared na primeira fase; o coordenador envia uma mensagem Commitna segunda fase.

Figura 14: O participante responde ReadOnly na primeira fase; n˜ao h´a segunda fase. Na realidade, WS-AtomicTransaction define duas varia¸c˜oes do 2PC:

• 2PC vol´atil: participantes cujos recursos transacionais s˜ao vol´ateis (por exemplo, um cache) devem se registrar nesse protocolo;

Figura 15: O participante responde Aborted na primeira fase; como s´o h´a um participante n˜ao h´a segunda fase.

• 2PC dur´avel: participantes cujos recursos transacionais s˜ao dur´aveis (por exemplo, um banco de dados ou uma fila de mensagens) devem se registrar nesse protocolo.

H´a uma justificativa para a existˆencia de duas varia¸c˜oes do protocolo 2PC. Alguns partici- pantes de uma transa¸c˜ao que interagem intensamente com algum meio de armazenamento persis- tente (por exemplo o disco r´ıgido) podem impor uma sobrecarga consider´avel sobre o tempo de execu¸c˜ao da transa¸c˜ao. Uma solu¸c˜ao natural para esse problema seria fazer um cache em mem´oria dos dados presentes no meio de armazenamento persistente. Durante a execu¸c˜ao da transa¸c˜ao, os participantes trabalhariam apenas com os dados presentes nesse cache. Isso funciona muito bem, desde que os dados presentes no cache sejam transferidos para o meio de armazenamento persis- tente antes da transa¸c˜ao iniciar o seu processo de encerramento. ´E por esse motivo que existe o 2PC vol´atil: participantes que se registraram nesse protocolo recebem a mensagem Prepare antes dos participantes que se registraram no protocolo 2PC dur´avel. Isso d´a aos participantes do 2PC vol´atil a chance de transferirem os seus dados de um meio vol´atil (um cache, por exemplo) para um meio persistente (um banco de dados, por exemplo), antes que qualquer notifica¸c˜ao seja enviada aos participantes que gerenciam recursos dur´aveis.

Ap´os enviar as mensagens Prepare a todos os participantes do 2PC vol´atil, o coordenador da transa¸c˜ao inicia a execu¸c˜ao do protocolo 2PC para os recursos que se registraram no 2PC dur´avel. Assim que o coordenador terminar de executar o 2PC para todos os recursos dur´aveis, os participantes do 2PC vol´atil ser˜ao informados sobre o desfecho da transa¸c˜ao. Vale ressaltar, por´em, que essa notifica¸c˜ao dos participantes do 2PC vol´atil ´e apenas uma cortesia, pois a transa¸c˜ao j´a ter´a sido encerrada quando tais notifica¸c˜oes forem enviadas (todos os recursos dur´aveis j´a ter˜ao recebido a ´ultima mensagem do 2PC antes de qualquer recurso vol´atil receber a notifica¸c˜ao do desfecho da transa¸c˜ao). Como a notifica¸c˜ao dos participantes do 2PC vol´atil ´e apenas uma cortesia, ela pode eventualmente n˜ao ocorrer (em casos de falhas, por exemplo).