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
54 CAPÍTULO 4. DESCRIÇÃO DAS FUNCIONALIDADES PRINCIPAIS DO SISTEMA DOORS resumo das operações executadas nos clientes por um período de tempo suficientemente grande. Outras aproximações possíveis foram propostas na literatura [5]. Uma segunda limitação da informação utilizada consiste no facto de os clientes apenas poderem propagar cada sequência de operações para um só servidor. Esta limitação resulta do identificador de uma sequência de operações ser atribuído quando as operações são recebidas no servidor (se uma operação fosse propagada para dois servidores seria tomada como duas operações diferentes). Uma solução para este problema consiste na atribuição de um identificador único a cada sequência de operações (como proposto anteriormente). O componente de reconciliação usa o identificador único para determinar se a operação já foi executada (uma aproximação semelhante é usada no sistema lazy replication [93]). Uma terceira limitação consiste na impossibilidade de executar uma operação com identificador (s,n) sem executar todas as operações com identificador (s,i) : i < n. Esta limitação é consequência do sumário das operações executadas ser um vector-versão. Como consequência, a execução de algumas operações numa réplica pode ser atrasada. Esta limitação pode ser ultrapassada, por exemplo, definindo o sumário das operações executadas como a combinação do vector-versão com o conjunto dos identificadores das operações executadas não reflectidas no vector-versão. No entanto, como se antevê que, devido ao modelo de funcionamento do sistema (propagação epidémica entre servidores e os clientes tendem a contactar sempre o mesmo servidor), as situações em que se verifica algum atraso na execução de uma operação são diminutas, pensa-se que a complexidade adicional não compensa. 4.1.2 Sem ordem A estratégia mais simples de execução das operações consiste em não impor nenhuma restrição à execu- ção das operações, as quais podem ser executadas por ordens diferentes nas várias réplicas. Para tal, o componente de reconciliação sem ordem executa todas as operações imediatamente após a sua recepção (de um cliente ou de outro servidor). Os blocos só-uma-vez apenas são executados no servidor em que a operação é recebida do cliente. Como uma operação recebida de um cliente é executada imediatamente, garante-se que todos os blocos só-uma-vez são executados. Neste caso, cada réplica reflecte sempre todas as operações conhecidas. O resultado final de uma operação propagada para um servidor é obtido imediatamente. No entanto, como as operações são exe- cutadas por ordem diferente nas várias réplicas, de um modo geral, não é possível garantir que o resultado (efeito) da execução de uma operação é idêntico em todas as réplicas. Assim, caso se pretenda obter a equivalência final das réplicas, este componente apenas pode ser usados quando é possível executar as operações por ordem diferente (por exemplo, quando todas as operações definidas são comutativas entre si).
4.1. RECONCILIAÇÃO 55 4.1.3 Ordem causal Uma operação é executada por ordem causal quando apenas é executada após terem sido executadas todas as operações conhecidas no momento da sua submissão no cliente. A ordem causal não garante que as operações sejam executadas pela mesma ordem em todas as réplicas. Assim, não é possível, no caso geral, garantir que os coobjectos convergem para o mesmo estado. O componente de reconciliação ordem causal pessimista executa imediatamente todas as operações conhecidas com as dependências causais satisfeitas (e que podem ser executadas face às limitações apre- sentadas anteriormente). Assim, cada réplica pode não reflectir todas as operações conhecidas. Para conhecer imediatamente o resultado de uma operação é necessário propagar a operação para um servidor que conheça todas as operações reflectidas na cópia do cliente. O servidor a partir do qual a cópia foi obtida satisfaz esta propriedade. Os blocos só-uma-vez são executados no servidor que recebeu a operação do cliente. No entanto, como as operações podem não ser executadas imediatamente quando são recebidas, é necessário garantir que quando um servidor é removido do grupo de replicadores do volume, os blocos só-uma-vez de todas as operações recebidas nesse servidor são executadas. No sistema DOORS, um servidor abandona voluntariamente o grupo de replicadores de um volume através de um protocolo que estabelece com apenas outro replicador do volume, que assume o papel de patrocinador. Durante este protocolo, apresentado na secção 6.2.1 e detalhado nos apêndices A.1.4 e A.1.8, o servidor a remover delega na réplica do servidor patrocinador a responsabilidade de executar os blocos só-uma-vez não executados localmente. Antes de ser removido, o servidor a remover executa ainda os blocos só-uma-vez relativos às operações que o patrocinador já tenha executado. Quando se processa a remoção forçada de um servidor que falhou definitivamente, é impossível determinar as operações que esse servidor já executou. Assim, não se delega em nenhum servidor a execução dos blocos só-uma-vez das operações recebidas no servidor avariado. É por esta razão que a semântica exacta de execução destes blocos é no máximo uma vez. 4.1.4 Ordem total As operações são executadas por ordem total quando, em todas as réplicas, são executadas pela mesma ordem. Neste caso, se as operações forem deterministas, garante-se que as várias réplicas do coobjecto convergem para o mesmo estado. De seguida, apresentam-se as várias estratégias utilizadas para garantir a execução das operações por ordem total.
- Page 21 and 22: 1.2. SISTEMAS DISTRIBUÍDOS DE GEST
- Page 23 and 24: 1.3. VISÃO GERAL E CONTRIBUIÇÕES
- Page 25 and 26: 1.3. VISÃO GERAL E CONTRIBUIÇÕES
- Page 27 and 28: Capítulo 2 Princípios gerais No c
- Page 29 and 30: 2.2. MOTIVAÇÃO - ALGUMAS APLICAÇ
- Page 31 and 32: 2.3. PRINCÍPIOS 13 garantir a disp
- Page 33 and 34: 2.3. PRINCÍPIOS 15 obter o estado
- Page 35 and 36: 2.3. PRINCÍPIOS 17 sobre a evoluç
- Page 37 and 38: 2.3. PRINCÍPIOS 19 2.3.6 Invocaç
- Page 39 and 40: 2.3. PRINCÍPIOS 21 solúveis). As
- Page 41 and 42: Capítulo 3 Apresentação do siste
- Page 43 and 44: 3.1. MODELO GERAL 25 para a activid
- Page 45 and 46: 3.1. MODELO GERAL 27 Aplicação At
- Page 47 and 48: 3.2. FRAMEWORK DE COMPONENTES: PRIN
- Page 49 and 50: 3.2. FRAMEWORK DE COMPONENTES: PRIN
- Page 51 and 52: 3.2. FRAMEWORK DE COMPONENTES: PRIN
- Page 53 and 54: 3.2. FRAMEWORK DE COMPONENTES: PRIN
- Page 55 and 56: 3.3. FRAMEWORK DE COMPONENTES: COMP
- Page 57 and 58: 3.3. FRAMEWORK DE COMPONENTES: COMP
- Page 59 and 60: 3.3. FRAMEWORK DE COMPONENTES: COMP
- Page 61 and 62: 3.3. FRAMEWORK DE COMPONENTES: COMP
- Page 63 and 64: 3.3. FRAMEWORK DE COMPONENTES: COMP
- Page 65 and 66: 3.4. FRAMEWORK DE COMPONENTES: IMPL
- Page 67 and 68: 3.4. FRAMEWORK DE COMPONENTES: IMPL
- Page 69 and 70: Capítulo 4 Descrição das funcion
- Page 71: 4.1. RECONCILIAÇÃO 53 Segundo, um
- Page 75 and 76: 4.1. RECONCILIAÇÃO 57 4.1.4.2 Ver
- Page 77 and 78: 4.1. RECONCILIAÇÃO 59 No decurso
- Page 79 and 80: 4.3. INVOCAÇÃO CEGA 61 4.3 Invoca
- Page 81 and 82: 4.4. INTEGRAÇÃO DE SESSÕES SÍNC
- Page 83 and 84: 4.4. INTEGRAÇÃO DE SESSÕES SÍNC
- Page 85 and 86: 4.4. INTEGRAÇÃO DE SESSÕES SÍNC
- Page 87 and 88: Capítulo 5 Avaliação do modelo d
- Page 89 and 90: 5.1. EDITOR MULTI-SÍNCRONO DE DOCU
- Page 91 and 92: 5.1. EDITOR MULTI-SÍNCRONO DE DOCU
- Page 93 and 94: 5.1. EDITOR MULTI-SÍNCRONO DE DOCU
- Page 95 and 96: 5.2. AGENDA PARTILHADA 77 Figura 5.
- Page 97 and 98: 5.2. AGENDA PARTILHADA 79 de awaren
- Page 99 and 100: Capítulo 6 Núcleo do sistema DOOR
- Page 101 and 102: 6.1. COOBJECTOS 83 o mesmo estado i
- Page 103 and 104: 6.2. SERVIDORES 85 global a associa
- Page 105 and 106: 6.2. SERVIDORES 87 segundo servidor
- Page 107 and 108: 6.2. SERVIDORES 89 6.2.2 Sincroniza
- Page 109 and 110: 6.2. SERVIDORES 91 6.2.3 Serviço d
- Page 111 and 112: 6.2. SERVIDORES 93 ao cliente compl
- Page 113 and 114: 6.2. SERVIDORES 95 • Emulação d
- Page 115 and 116: 6.3. CLIENTES 97 do coobjecto consi
- Page 117 and 118: 6.3. CLIENTES 99 seguinte informaç
- Page 119 and 120: 6.3. CLIENTES 101 A propagação as
- Page 121 and 122: Capítulo 7 Apresentação do siste
54 CAPÍTULO 4. DESCRIÇÃO DAS FUNCIONALIDADES PRINCIPAIS DO SISTEMA DOORS<br />
resumo das operações executadas nos clientes por um período <strong>de</strong> t<strong>em</strong>po suficient<strong>em</strong>ente gran<strong>de</strong>. Outras<br />
aproximações possíveis foram propostas na literatura [5].<br />
Uma segunda limitação da informação utilizada consiste no facto <strong>de</strong> os clientes apenas po<strong>de</strong>r<strong>em</strong><br />
propagar cada sequência <strong>de</strong> operações para um só servidor. Esta limitação resulta do i<strong>de</strong>ntificador <strong>de</strong> uma<br />
sequência <strong>de</strong> operações ser atribuído quando as operações são recebidas no servidor (se uma operação<br />
fosse propagada para dois servidores seria tomada como duas operações diferentes). Uma solução para<br />
este probl<strong>em</strong>a consiste na atribuição <strong>de</strong> um i<strong>de</strong>ntificador único a cada sequência <strong>de</strong> operações (como<br />
proposto anteriormente). O componente <strong>de</strong> reconciliação usa o i<strong>de</strong>ntificador único para <strong>de</strong>terminar se a<br />
operação já foi executada (uma aproximação s<strong>em</strong>elhante é usada no sist<strong>em</strong>a lazy replication [93]).<br />
Uma terceira limitação consiste na impossibilida<strong>de</strong> <strong>de</strong> executar uma operação com i<strong>de</strong>ntificador (s,n)<br />
s<strong>em</strong> executar todas as operações com i<strong>de</strong>ntificador (s,i) : i < n. Esta limitação é consequência do sumário<br />
das operações executadas ser um vector-versão. Como consequência, a execução <strong>de</strong> algumas operações<br />
numa réplica po<strong>de</strong> ser atrasada. Esta limitação po<strong>de</strong> ser ultrapassada, por ex<strong>em</strong>plo, <strong>de</strong>finindo o sumário<br />
das operações executadas como a combinação do vector-versão com o conjunto dos i<strong>de</strong>ntificadores das<br />
operações executadas não reflectidas no vector-versão. No entanto, como se antevê que, <strong>de</strong>vido ao<br />
mo<strong>de</strong>lo <strong>de</strong> funcionamento do sist<strong>em</strong>a (propagação epidémica entre servidores e os clientes ten<strong>de</strong>m a<br />
contactar s<strong>em</strong>pre o mesmo servidor), as situações <strong>em</strong> que se verifica algum atraso na execução <strong>de</strong> uma<br />
operação são diminutas, pensa-se que a complexida<strong>de</strong> adicional não compensa.<br />
4.1.2 S<strong>em</strong> or<strong>de</strong>m<br />
A estratégia mais simples <strong>de</strong> execução das operações consiste <strong>em</strong> não impor nenhuma restrição à execu-<br />
ção das operações, as quais po<strong>de</strong>m ser executadas por or<strong>de</strong>ns diferentes nas várias réplicas.<br />
Para tal, o componente <strong>de</strong> reconciliação s<strong>em</strong> or<strong>de</strong>m executa todas as operações imediatamente após<br />
a sua recepção (<strong>de</strong> um cliente ou <strong>de</strong> outro servidor). Os blocos só-uma-vez apenas são executados no<br />
servidor <strong>em</strong> que a operação é recebida do cliente. Como uma operação recebida <strong>de</strong> um cliente é executada<br />
imediatamente, garante-se que todos os blocos só-uma-vez são executados.<br />
Neste caso, cada réplica reflecte s<strong>em</strong>pre todas as operações conhecidas. O resultado final <strong>de</strong> uma<br />
operação propagada para um servidor é obtido imediatamente. No entanto, como as operações são exe-<br />
cutadas por or<strong>de</strong>m diferente nas várias réplicas, <strong>de</strong> um modo geral, não é possível garantir que o resultado<br />
(efeito) da execução <strong>de</strong> uma operação é idêntico <strong>em</strong> todas as réplicas. Assim, caso se pretenda obter a<br />
equivalência final das réplicas, este componente apenas po<strong>de</strong> ser usados quando é possível executar as<br />
operações por or<strong>de</strong>m diferente (por ex<strong>em</strong>plo, quando todas as operações <strong>de</strong>finidas são comutativas entre<br />
si).