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
200 APÊNDICE A. DOORS lado, na cópia j, tem-se necessariamente v[m] < n, porque a execução de op j, posterior a opi, impede esta de ser executada (e a ordem definida garante que nenhuma outra operação submetida no servidor identificado por m pode ser executada). Nesta cópia, é impossível que o servidor associado a m tenha sido removido (porque o modo de funcionamento do coobjecto garante que uma operação de remoção apenas é executada após a execução de todas as operações submetidas nesse servidor). Desta forma, a execução de dois conjuntos diferentes de operações leva a que o identificador da vista seja igualmente diferente. A.1.2 Protocolo local de mudança de vista O protocolo local de mudança de vista é executado localmente num servidor sempre que é necessário modificar o estado do coobjecto de filiação. Este protocolo executa, de forma atómica, as actualizações necessárias nos identificadores dos servidores usados em todos os coobjectos do volume. No fim da execução do protocolo diz-se que foi instalada a vista definida pelo coobjecto de filiação. O protocolo local de mudança de vista consiste nos seguintes passos executados no servidor i, dado um conjunto de operações a executar sobre o coobjecto de filiação: 1. Qualquer acesso à cópia do volume no servidor i é impedido (incluindo os acessos aos coobjectos pertencentes a esse volume). 2. São executadas as operações desejadas no coobjecto de filiação (que podem incluir operações recebidas de outro servidor). O estado final do coobjecto define a nova vista que vai ser instalada na cópia do volume. 3. Se um novo identificador de vista foi definido (i.e., se foi executada alguma operação que al- tere a filiação), todos os coobjectos são informados da nova vista e das mudanças necessárias para converter os identificadores antigos nos novos. Normalmente, os identificadores já existentes mantêm-se e não é necessário executar nenhuma acção nos coobjectos. 4. O protocolo termina e permite-se, de novo, o acesso à cópia do volume. Se durante a execução do protocolo existir alguma falha no servidor, o protocolo volta a ser reiniciado no ponto onde falhou. As falhas na execução do protocolo são detectadas da seguinte forma. O início do protocolo é registado em memória estável, onde se guarda a data de início — após a conclusão do protocolo esta informação é removida. Quando um servidor é reiniciado, qualquer registo de início do protocolo na memória estável corresponde a uma execução não terminada. Uma falha durante o passo 2 é detectada pelo facto de o estado do coobjecto de filiação guardado em memória estável ter uma data são submetidas).
A.1. FILIAÇÃO 201 anterior à de início de protocolo. A detecção de falhas durante a execução do passo 3 é efectuada de forma idêntica para cada coobjecto. A.1.3 Protocolo de entrada no grupo de replicadores de um volume O protocolo de entrada no grupo de replicadores de um volume controla a entrada de um novo servidor no grupo de servidores que replicam um volume. Nesta situação, é necessário actualizar o coobjecto de filiação e propagar um cópia do volume para o novo servidor. O protocolo de entrada no grupo de replicadores de um volume v do servidor i, tendo como patroci- nador o servidor j pertencente ao grupo de replicadores de v, tem os seguintes passos: 1. i comunica a j o desejo de entrar no grupo e indica-lhe o identificador único que usará idi. Até à conclusão do protocolo, o servidor j fica impedido de participar em protocolos de remoção voluntária do grupo de replicadores. 2. O servidor j executa o protocolo local de mudança de vista no volume v usando a operação de inserção no grupo do servidor i com identificador único idi. 3. O servidor j envia para o servidor i o estado actual da sua cópia do volume durante uma sessão de sincronização epidémica, incluindo uma cópia de todos os coobjectos existentes — quando uma cópia de um coobjecto é instanciada pela primeira vez num servidor, é executada uma operação na interface do coobjecto a informar o coobjecto dessa situação. Após a recepção do coobjecto de filiação, o servidor i pode iniciar imediatamente a sua operação (embora se espere pela recepção de todo o estado do volume, a menos que exista alguma falha). Se durante a execução do protocolo existir alguma falha, o protocolo é reiniciado, reexecutando o passo em que falhou — as falhas no passo 2 são resolvidas como explicado anteriormente. As falhas durante a propagação do estado do volume são resolvidas através da execução de uma nova sessão de sincronização epidémica. A.1.3.1 Condições suficientes para a ordenação correcta de operações usando técnicas de verifi- cação da estabilidade da ordem Quando um novo servidor se junta ao grupo de replicadores de um volume, o seu identificador é provi- sório até se garantir que a operação de inserção executada no coobjecto de filiação não será desfeita no futuro. Assim, quando se usam as técnicas de estabilidade descritas na secção 4.1, não se deve usar a informação relativa aos servidores que têm identificadores provisórios 3 . 3 O identificador de um servidor adicionado ao grupo de replicadores de um volume pela operação de adição com identifica- dor (srvvol,n_seq) é provisório sse essa operação de adição ainda não foi ordenada de forma definitiva na réplica do coobjecto
- Page 167 and 168: Capítulo 10 Sistema de reconcilia
- Page 169 and 170: 10.2. RELAÇÕES ESTÁTICAS 151 10.
- Page 171 and 172: 10.3. ALGORITMO DE RECONCILIAÇÃO
- Page 173 and 174: 10.3. ALGORITMO DE RECONCILIAÇÃO
- Page 175 and 176: 10.3. ALGORITMO DE RECONCILIAÇÃO
- 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: A.1. FILIAÇÃO 199 A operação 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 and 228: A.1. FILIAÇÃO 209 estas situaçõ
- Page 229 and 230: A.1. FILIAÇÃO 211 2. Um servidor
- 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
200 APÊNDICE A. DOORS<br />
lado, na cópia j, t<strong>em</strong>-se necessariamente v[m] < n, porque a execução <strong>de</strong> op j, posterior a opi, impe<strong>de</strong><br />
esta <strong>de</strong> ser executada (e a or<strong>de</strong>m <strong>de</strong>finida garante que nenhuma outra operação submetida no servidor<br />
i<strong>de</strong>ntificado por m po<strong>de</strong> ser executada). Nesta cópia, é impossível que o servidor associado a m tenha<br />
sido r<strong>em</strong>ovido (porque o modo <strong>de</strong> funcionamento do coobjecto garante que uma operação <strong>de</strong> r<strong>em</strong>oção<br />
apenas é executada após a execução <strong>de</strong> todas as operações submetidas nesse servidor). Desta forma, a<br />
execução <strong>de</strong> dois conjuntos diferentes <strong>de</strong> operações leva a que o i<strong>de</strong>ntificador da vista seja igualmente<br />
diferente.<br />
A.1.2 Protocolo local <strong>de</strong> mudança <strong>de</strong> vista<br />
O protocolo local <strong>de</strong> mudança <strong>de</strong> vista é executado localmente num servidor s<strong>em</strong>pre que é necessário<br />
modificar o estado do coobjecto <strong>de</strong> filiação. Este protocolo executa, <strong>de</strong> forma atómica, as actualizações<br />
necessárias nos i<strong>de</strong>ntificadores dos servidores usados <strong>em</strong> todos os coobjectos do volume. No fim da<br />
execução do protocolo diz-se que foi instalada a vista <strong>de</strong>finida pelo coobjecto <strong>de</strong> filiação.<br />
O protocolo local <strong>de</strong> mudança <strong>de</strong> vista consiste nos seguintes passos executados no servidor i, dado<br />
um conjunto <strong>de</strong> operações a executar sobre o coobjecto <strong>de</strong> filiação:<br />
1. Qualquer acesso à cópia do volume no servidor i é impedido (incluindo os acessos aos coobjectos<br />
pertencentes a esse volume).<br />
2. São executadas as operações <strong>de</strong>sejadas no coobjecto <strong>de</strong> filiação (que po<strong>de</strong>m incluir operações<br />
recebidas <strong>de</strong> outro servidor). O estado final do coobjecto <strong>de</strong>fine a nova vista que vai ser instalada<br />
na cópia do volume.<br />
3. Se um novo i<strong>de</strong>ntificador <strong>de</strong> vista foi <strong>de</strong>finido (i.e., se foi executada alguma operação que al-<br />
tere a filiação), todos os coobjectos são informados da nova vista e das mudanças necessárias<br />
para converter os i<strong>de</strong>ntificadores antigos nos novos. Normalmente, os i<strong>de</strong>ntificadores já existentes<br />
mantêm-se e não é necessário executar nenhuma acção nos coobjectos.<br />
4. O protocolo termina e permite-se, <strong>de</strong> novo, o acesso à cópia do volume.<br />
Se durante a execução do protocolo existir alguma falha no servidor, o protocolo volta a ser reiniciado<br />
no ponto on<strong>de</strong> falhou. As falhas na execução do protocolo são <strong>de</strong>tectadas da seguinte forma. O início<br />
do protocolo é registado <strong>em</strong> m<strong>em</strong>ória estável, on<strong>de</strong> se guarda a data <strong>de</strong> início — após a conclusão do<br />
protocolo esta informação é r<strong>em</strong>ovida. Quando um servidor é reiniciado, qualquer registo <strong>de</strong> início do<br />
protocolo na m<strong>em</strong>ória estável correspon<strong>de</strong> a uma execução não terminada. Uma falha durante o passo 2<br />
é <strong>de</strong>tectada pelo facto <strong>de</strong> o estado do coobjecto <strong>de</strong> filiação guardado <strong>em</strong> m<strong>em</strong>ória estável ter uma data<br />
são submetidas).