Arquitetura interna: Referências e transações

Já vimos que uma aplicação chama métodos na referência exatamente da mesma forma que no objeto original: eles podem implementar a mesma interface:

 1:        //cria uma Offer
 2:        Offer offer = new OfferImpl("potato", 10.0, null);
 3:
 4:        //compartilha a Offer
 5:        shob.share("offer1", offer, "auction.core.OfferReference");
 6:        offer = shob.get("offer1");

Parte da consistência é garantida porque uma referência contém apenas duas propriedades: um ponteiro para o SharedSpace e o nome global do objeto. Ao chamar um método na referência, os seguintes passos ocorrem:

1. A referência "desmonta" a chamada de método na tripla (nome, classes, valores) necessária para a reflexão.
2. Se o método envolve escrita, a referência pede inicia uma transação no objeto (beginTrans).
3. A seguir, pede que a SharedSpace execute o método na cópia local.
4. A SharedSpace localiza no cache o objeto e, por reflexão, chama o método pedido.
5. Se o método é de escrita e tudo correu bem, a referência conclui com sucesso a transação (commit).
   • Se houve alguma exceção prevista pelo método, a referência conclui com fracasso a transação (rollback).
6. Caso o método-alvo tenha lançado uma exceção, essa é lançada novamente para a aplicação. Caso contrário, a referência devolve o valor de retorno esperado, quando houver.

Assim, pode-se perceber que o mecanismo não é em si complicado. Alguns cuidados a mais são tomados quando a chamada envolve uma transação. Para iniciar uma transação, o SharedSpace requisita ao servidor de nomes o lock de escrita do objeto. Caso o cache esteja desatualizado, uma nova cópia é pedida ao seu dono.

1) Pedido de transação: o SharedSpace informa que uma transação no objeto está prestes a começar. O timestamp da cópia atual também é fornecido 2) OK + validação: se não há uma transação em curso, o servidor dá ao Cliente 1 autorização para escrita. Além disso, o timestamp é validado pelo servidor: caso a cópia atual não seja a última, o cliente precisa pegar a versão atual novamente 3) Pedido: só ocorre quando o cliente 1 precisa atualizar sua cópia: um pedido é enviado ao dono do objeto (Cliente 2) solicitando a versão atual do objeto 4) Resposta: o dono do objeto envia ao escritor a versão atual do objeto, sem risco de que ela seja alterada após o início da transação

Begin Transaction

No final da execução, o SharedSpace pode requisitar um commit. No SharedObjects, utilizamos uma variação do commit de duas fases proposto por @link{Shuberries(fonte do algoritmo)}:

1. Quem recebe o timestamp?
2. O SharedSpace informa ao servidor que um commit foi iniciado
3. O servidor de nomes notifica o dono do objeto que uma cópia modificada está pronta para se tornar a versão oficial do objeto e dá ao dono um timestamp de controle.
4. O dono do objeto requisita a cópia modificada para o nosso SharedSpace. Ao guardar o novo objeto, o dono associa a ele o timestamp fornecido pelo servidor.
5. O dono do objeto informa o servidor que a nova versão está disponível e este libera o lock de escrita do objeto.

1) Pedido de commit: o escritor informa ao servidor que ele deseja iniciar o commit 2) Aviso de commit: o servidor informa ao dono do objeto que uma nova versão está disponível 3) Pedido: o dono do objeto pede a cópia modificada para o escritor 4) Resposta: o escritor responde enviando o objeto modificado ao seu dono 5) Fim do commit: o dono avisa o servidor que a nova cópia está salva e o objeto está disponível para novas escritas

Commit

Quando um método falha, a cópia fica inválida, pois não podemos prever o estado interno do objeto. O processo de rollback é iniciado:

1. O SharedSpace informa ao servidor que a transação falhou.
2. O servidor de nomes libera o lock de escrita do objeto.
3. O SharedSpace pede, ao dono do objeto, uma nova cópia.
   

1) Pedido de rollback: o escritor informa ao servidor que ele deseja encerrar a transação com rollback 2) Rollback: o servidor informa ao escritor que sua transação será desfeita e que ele deve recuperar a versão que o dono possui. A partir desse momento, novas transações já podem ser iniciadas. 3) Pedido: o escritor pede a cópia anterior para o dono do objeto 4) Resposta: o dono responde enviando o objeto sem alterações ao escritor

Rollback

• Anterior: Servidor de nomes
• Próxima: Leases: percebendo mudanças