gestão de dados partilhados em ambientes de computação móvel

A.1. FILIAÇÃO 209
estas situações, a última condição expressa anteriormente é generalizada para (considerando a remoção
conjunta de um conjunto R de servidores, sendo que o conjunto S de servidores não removidos — com
U = R∪S, o conjunto de servidores que replica o volume — define um quorum (neste caso, uma maioria)
no sistema U):
• A remoção forçada de um conjunto R de servidores pode prosseguir se o servidor com menor nú-
mero de ordem, não contido em R, verificar que: (1) todos os servidores do volume, com excepção
dos servidores incluídos em R, concordaram com a remoção de todos os servidores em R (convém
realçar que é possível que alguns servidores em R tenham concordado com a remoção de outros
servidores presentes em R e tenham posteriormente sido alvo de remoção forçada); (2) o estado
actual do servidor reflecte os estados de todos os servidores no momento em que eles executaram a
última operação de concordância com a remoção de um servidor pertencente a R (ou seja, o estado
actual reflecte todas as operações submetidas pelos servidores em S).
Implementação Para implementar a estratégia descrita anteriormente, definiram-se as seguintes ope-
rações no coobjecto de filiação:
askRemove(uid,i) Pede a remoção do servidor i do grupo de replicadores, usando o identificador único
uid para identificar univocamente o pedido. Esta operação, quando executada, coloca o estado do
servidor i como a_remover(uid) (no caso de o estado já ser a_remover(uid0), a operação falha e é
submetida a operação rollbackRemove(uid)) 5 .
agreeRemove(j,uid) Indica a concordância do servidor j com o pedido de remoção (do servidor i) com
identificador uid. O coobjecto de filiação mantém, para cada pedido de remoção de um servidor, a
lista de servidores que afirmaram a sua concordância com essa remoção. Após a submissão desta
operação, o servidor j não pode retroceder na sua intenção de remover i, nem estabelecer qual-
quer sessão de sincronização com i, a menos que seja executada uma operação de rollbackRemove
noutro servidor. Um servidor l que inicie a replicação de um volume deve executar a acção agree-
Remove(l,uid) se o seu patrocinador, o servidor j, tiver executado a operação agreeRemove(j,uid)
5 A execução optimista das operações no coobjecto de filiação pode levar a que a primeira execução da operação askRe-
move(uid,i) coloque o estado do servidor i como a_remover(uid), enquanto na execução definitiva se verifique que já existe
outro pedido anterior para a remoção do mesmo servidor i — esta situação não afecta a correcção do funcionamento do sis-
tema, devendo em cada execução serem executadas as acções indicadas. Quando a execução optimista da operação é desfeita,
o estado associado ao servidor i é reposto no estado anterior, mas as operações submetidas em consequências da primeira exe-
cução não são removidas (uma optimização possível é submeter a operação de rollbackRemove apenas uma vez). A correcção
de funcionamento do sistema também não é afectada se aquando da execução definitiva, ao contrário do que aconteceu numa
execução optimista, o estado do servidor i não for activo — as operações de rollbackRemove(uid) encarregam-se de abortar
este pedido. Neste caso, um novo pedido deve ser efectuado posteriormente.