gestão de dados partilhados em ambientes de computação móvel
gestão de dados partilhados em ambientes de computação móvel gestão de dados partilhados em ambientes de computação móvel
210 APÊNDICE A. DOORS antes de executar a operação de inserção de l no grupo de replicadores do volume. Caso contrário, o servidor l pode tomar uma posição independente. rollbackRemove(uid) Indica que o pedido de remoção (do servidor i) com identificador uid deve ser cancelado. A execução desta operação recoloca o estado de i em activo (e permite que os servidores que tinham dado a sua concordância com a remoção de i possam voltar a comunicar com i). readyRemove(uid) Indica que a cópia local do servidor está pronta para concluir o pedido de remo- ção forçada. A remoção apenas se executará se os outros servidores tiverem concordado com a remoção (como se explicou anteriormente). Usando estas operações e a operação de disseminação definida anteriormente, a remoção forçada de um servidor i do grupo de replicadores do volume v processa-se da seguinte forma: 1. Um qualquer servidor j, pertencente ao grupo de replicadores do volume v, submete as operações askRemove(uid,i) e disseminate(uidd,U,readyRemove(uid),readyCond) no coobjecto de filia- ção do volume v. A operação askRemove dá início ao processo de remoção forçada de um servidor — a sua execução com sucesso coloca o estado do servidor em a_remover(uid). A operação de disseminação garante a propagação das operações identificadas no servidor i para todos os repli- cadores do volume. A condição readyCond verifica se as condições para a execução da operação readyRemove (descri- tas anteriormente) são satisfeitas, i.e., se todos os servidores que não vão ser removidos concordam com a remoção e se, para todos os coobjectos, todas as operações submetidas em i, e conhecidas em qualquer servidor aquando da execução da operação agreeRemove, estão reflectidas na réplica local do coobjecto 6 . Assim, readyCond será verdadeiro no servidor i, quando: (1) todos os servidores que não vão ser removidos submeteram a operação agreeRemove respectiva; (2) para todo o servidor activo, j, que submeteu a operação agreeRemove( j,uid) identificada em j com o número de sequência tcr, se tem v[i, j] ≥ tcr; (3) para todo o servidor removido j, removido pela operação de remoção sub- metida no patrocinador k com número de sequência tr j, se tem v[i,k] ≥ tr j 7 . Se o servidor k tiver posteriormente sido removido pela operação de remoção submetida no patrocinador l com número de sequência trk, deve ter-se v[i,k] ≥ tt j ∨ v[i,l] ≥ trk (e de modo semelhante para consecutivas remoções). 6 O facto de a operação agreeRemove ser executada independentemente da operação de disseminação leva a que a condição definida por omissão não seja válida neste caso. 7 Se o servidor removido, j, tiver submetido a operação agreeRemove( j,uid), basta verificar a primeira condição.
A.1. FILIAÇÃO 211 2. Um servidor j, no qual o estado do servidor i é a_remover(uid), após executar as verificações que considere necessárias, deve submeter a operação agreeRemove( j,uid) ou rollback(uid) se, respectivamente, concordar ou discordar da remoção do servidor (e, caso concorde, actuar em conformidade com essa decisão). 3. A execução da operação readyRemove no servidor i, verifica se i é o responsável por efectuar a remoção, considerando todos os pedidos de remoção pendentes (i.e., se é o servidor com menor número de ordem na vista actual dos servidores que não se incluem no conjunto de servidores prontos a serem removidos). O responsável pela remoção, actua como patrocinador da remoção e executa as seguintes operações (sem permitir acessos concorrentes de outros servidores ou clien- tes): (1) informa todos os coobjectos do volume quais são os servidores que vão ser removidos; (2) submete as operações de remoção respectivas (através do protocolo local de mudança de vista). O mecanismo de remoção forçada de um servidor leva a que operações propagadas por um cliente para o servidor removido sejam perdidas caso não tenham sido anteriormente propagadas para outro servidor que permaneça no sistema. Assim, este mecanismo apenas deve ser usado em relação aos servi- dores que se encontram permanentemente desconectados do sistema (por exemplo, devido a terem sido danificados). Se um servidor removido não estiver permanentemente desconectado, ele deve propagar as operações que recebeu de clientes para um servidor que esteja a replicar o volume e, caso pretenda, pedir a sua inserção no grupo de replicadores. A.1.8 Protocolo de execução dos blocos só-uma-vez em ordenações por verificação da estabilidade Nos protocolos que ordenam as operações verificando a estabilidade da ordem (ordem causal – sec- ção 4.1.3, ordem total – secção 4.1.4.2), quando um servidor sai voluntariamente do grupo de replica- dores de um volume, o patrocinador assume a responsabilidade de executar os blocos só-uma-vez das operações que ainda não tenham sido executadas no servidor removido. No entanto, como o patroci- nador pode já ter executado algumas das operações das quais devia executar os blocos só-uma-vez, o seguinte protocolo é usado para garantir que os blocos só-uma-vez são executados uma e uma só vez: 1. Quando a réplica de um coobjecto num servidor é informada que esse servidor vai ser removido do grupo de replicadores (passo 4 do protocolo de remoção), executa uma operação que indica quais as operações executadas até esse momento e quais as operações pelas quais é responsável por executar os blocos só-uma-vez (neste caso, as operações recebidas no servidor e aquelas cuja responsabilidade possa ter sido delegada anteriormente). Esta operação delega no patrocinador a responsabilidade de executar os blocos só-uma-vez das operações ainda não executadas.
- Page 177 and 178: 10.4. OPTIMIZAÇÃO DA RECONCILIAÇ
- Page 179 and 180: 10.5. EXTRACÇÃO AUTOMÁTICA DE RE
- Page 181 and 182: 10.5. EXTRACÇÃO AUTOMÁTICA DE RE
- Page 183 and 184: 10.5. EXTRACÇÃO AUTOMÁTICA DE RE
- Page 185 and 186: 10.5. EXTRACÇÃO AUTOMÁTICA DE RE
- Page 187 and 188: 10.5. EXTRACÇÃO AUTOMÁTICA DE RE
- Page 189 and 190: 10.5. EXTRACÇÃO AUTOMÁTICA DE RE
- Page 191 and 192: Capítulo 11 Trabalho relacionado A
- Page 193 and 194: 11.1. REPLICAÇÃO 175 11.1.2 Arqui
- Page 195 and 196: 11.1. REPLICAÇÃO 177 a unidade de
- Page 197 and 198: 11.1. REPLICAÇÃO 179 O mecanismo
- Page 199 and 200: 11.1. REPLICAÇÃO 181 dade 3 . Est
- Page 201 and 202: 11.1. REPLICAÇÃO 183 e ser propag
- Page 203 and 204: 11.1. REPLICAÇÃO 185 ordem de exe
- Page 205 and 206: 11.1. REPLICAÇÃO 187 execução d
- Page 207 and 208: 11.2. INFORMAÇÃO SOBRE A EVOLUÇ
- Page 209 and 210: 11.3. INTEGRAÇÃO DE SESSÕES SÍN
- Page 211 and 212: Capítulo 12 Conclusões A generali
- Page 213 and 214: 12.1. SUMÁRIO 195 é executado no
- Page 215 and 216: Apêndice A DOORS Este apêndice ap
- Page 217 and 218: A.1. FILIAÇÃO 199 A operação de
- Page 219 and 220: A.1. FILIAÇÃO 201 anterior à de
- Page 221 and 222: A.1. FILIAÇÃO 203 associados e o
- Page 223 and 224: A.1. FILIAÇÃO 205 Actualização
- Page 225 and 226: A.1. FILIAÇÃO 207 • Periodicame
- Page 227: A.1. FILIAÇÃO 209 estas situaçõ
- Page 231 and 232: A.2. SINCRONIZAÇÃO EPIDÉMICA 213
- Page 233 and 234: A.2. SINCRONIZAÇÃO EPIDÉMICA 215
- Page 235 and 236: A.2. SINCRONIZAÇÃO EPIDÉMICA 217
- Page 237 and 238: A.2. SINCRONIZAÇÃO EPIDÉMICA 219
- Page 239 and 240: Apêndice B Mobisnap B.1 Transacç
- Page 241 and 242: Bibliografia [1] S. Agarwal, D. Sta
- Page 243 and 244: BIBLIOGRAFIA 225 [22] Michael J. Ca
- Page 245 and 246: BIBLIOGRAFIA 227 [45] Sérgio Duart
- Page 247 and 248: BIBLIOGRAFIA 229 [67] Jörg M. Haak
- Page 249 and 250: BIBLIOGRAFIA 231 [92] David Lacey,
- Page 251 and 252: BIBLIOGRAFIA 233 [120] Vern E. Paxs
- Page 253 and 254: BIBLIOGRAFIA 235 [139] David Ratner
- Page 255: BIBLIOGRAFIA 237 third internationa
210 APÊNDICE A. DOORS<br />
antes <strong>de</strong> executar a operação <strong>de</strong> inserção <strong>de</strong> l no grupo <strong>de</strong> replicadores do volume. Caso contrário,<br />
o servidor l po<strong>de</strong> tomar uma posição in<strong>de</strong>pen<strong>de</strong>nte.<br />
rollbackR<strong>em</strong>ove(uid) Indica que o pedido <strong>de</strong> r<strong>em</strong>oção (do servidor i) com i<strong>de</strong>ntificador uid <strong>de</strong>ve ser<br />
cancelado. A execução <strong>de</strong>sta operação recoloca o estado <strong>de</strong> i <strong>em</strong> activo (e permite que os servidores<br />
que tinham dado a sua concordância com a r<strong>em</strong>oção <strong>de</strong> i possam voltar a comunicar com i).<br />
readyR<strong>em</strong>ove(uid) Indica que a cópia local do servidor está pronta para concluir o pedido <strong>de</strong> r<strong>em</strong>o-<br />
ção forçada. A r<strong>em</strong>oção apenas se executará se os outros servidores tiver<strong>em</strong> concordado com a<br />
r<strong>em</strong>oção (como se explicou anteriormente).<br />
Usando estas operações e a operação <strong>de</strong> diss<strong>em</strong>inação <strong>de</strong>finida anteriormente, a r<strong>em</strong>oção forçada <strong>de</strong><br />
um servidor i do grupo <strong>de</strong> replicadores do volume v processa-se da seguinte forma:<br />
1. Um qualquer servidor j, pertencente ao grupo <strong>de</strong> replicadores do volume v, submete as operações<br />
askR<strong>em</strong>ove(uid,i) e diss<strong>em</strong>inate(uidd,U,readyR<strong>em</strong>ove(uid),readyCond) no coobjecto <strong>de</strong> filia-<br />
ção do volume v. A operação askR<strong>em</strong>ove dá início ao processo <strong>de</strong> r<strong>em</strong>oção forçada <strong>de</strong> um servidor<br />
— a sua execução com sucesso coloca o estado do servidor <strong>em</strong> a_r<strong>em</strong>over(uid). A operação <strong>de</strong><br />
diss<strong>em</strong>inação garante a propagação das operações i<strong>de</strong>ntificadas no servidor i para todos os repli-<br />
cadores do volume.<br />
A condição readyCond verifica se as condições para a execução da operação readyR<strong>em</strong>ove (<strong>de</strong>scri-<br />
tas anteriormente) são satisfeitas, i.e., se todos os servidores que não vão ser r<strong>em</strong>ovidos concordam<br />
com a r<strong>em</strong>oção e se, para todos os coobjectos, todas as operações submetidas <strong>em</strong> i, e conhecidas<br />
<strong>em</strong> qualquer servidor aquando da execução da operação agreeR<strong>em</strong>ove, estão reflectidas na réplica<br />
local do coobjecto 6 .<br />
Assim, readyCond será verda<strong>de</strong>iro no servidor i, quando: (1) todos os servidores que não vão ser<br />
r<strong>em</strong>ovidos submeteram a operação agreeR<strong>em</strong>ove respectiva; (2) para todo o servidor activo, j, que<br />
submeteu a operação agreeR<strong>em</strong>ove( j,uid) i<strong>de</strong>ntificada <strong>em</strong> j com o número <strong>de</strong> sequência tcr, se<br />
t<strong>em</strong> v[i, j] ≥ tcr; (3) para todo o servidor r<strong>em</strong>ovido j, r<strong>em</strong>ovido pela operação <strong>de</strong> r<strong>em</strong>oção sub-<br />
metida no patrocinador k com número <strong>de</strong> sequência tr j, se t<strong>em</strong> v[i,k] ≥ tr j 7 . Se o servidor k tiver<br />
posteriormente sido r<strong>em</strong>ovido pela operação <strong>de</strong> r<strong>em</strong>oção submetida no patrocinador l com número<br />
<strong>de</strong> sequência trk, <strong>de</strong>ve ter-se v[i,k] ≥ tt j ∨ v[i,l] ≥ trk (e <strong>de</strong> modo s<strong>em</strong>elhante para consecutivas<br />
r<strong>em</strong>oções).<br />
6 O facto <strong>de</strong> a operação agreeR<strong>em</strong>ove ser executada in<strong>de</strong>pen<strong>de</strong>nt<strong>em</strong>ente da operação <strong>de</strong> diss<strong>em</strong>inação leva a que a condição<br />
<strong>de</strong>finida por omissão não seja válida neste caso.<br />
7 Se o servidor r<strong>em</strong>ovido, j, tiver submetido a operação agreeR<strong>em</strong>ove( j,uid), basta verificar a primeira condição.
Change language