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
86 CAPÍTULO 6. NÚCLEO DO SISTEMA DOORS De seguida, descreve-se o funcionamento do sistema de filiação implementado no sistema DOORS. Nesta descrição, indicam-se as acções a executar pelos servidores no âmbito da gestão de filiação de um dado volume, sendo que a gestão da filiação de cada volume é executada de forma independente. Coobjecto de filiação Em cada volume, a informação sobre o grupo de servidores que replica o volume é mantida num coobjecto especial manipulado pelo sistema, o coobjecto de filiação. Este coobjecto de- fine três operações de modificação: inserção de um novo servidor; remoção de um servidor; e eliminação das referências relativas a um servidor anteriormente removido. O estado do coobjecto de filiação define, em cada momento, uma vista (view) do grupo de replica- dores do volume que inclui: um identificador da vista; a identificação do conjunto de replicadores; e uma função bijectiva que atribui a cada replicador do volume um número inteiro, srvview, que o identi- fica na vista. Este identificador (srvview) é usado na identificação das operações, como se explicou na secção 4.1.1. Como se detalha no apêndice A.1.1, o funcionamento deste coobjecto garante que duas cópias que tenham conhecimento do mesmo conjunto de operações têm o mesmo estado (i.e., estão na mesma vista). Adicionalmente, garante-se que o identificador da vista a identifica univocamente, i.e., a cada conjunto de operações corresponde um e um só identificador e a cada identificador corresponde um e um só conjunto de operações. Protocolo local de mudança de vista Como se referiu anteriormente, as operações executadas em qualquer coobjecto de um volume são identificadas com um par que inclui o identificador do servidor na vista. Os sumários de operações mantidos são igualmente baseados nestes identificadores. Assim, é necessário actualizar estes identificadores sempre que se instala uma nova vista. Para tal, definiu-se o protocolo local de mudança de vista, detalhado no apêndice A.1.2. Este protocolo actualiza, de forma atómica, todos os coobjectos de um volume. O modo como o coobjecto de filiação é actualizado leva a que apenas sejam necessárias actualizações quando se verificam duas ou mais inserções concorrentes (e em que aos novos servidores foram atribuídos, na execução optimista, o mesmo identificador em diferentes cópias do mesmo volume) ou uma inserção concorrente com uma eliminação (em que o novo servidor pode reutilizar o identificador do servidor eliminado) 4 . Com base no coobjecto de filiação e no protocolo local de mudança de vista, os protocolos de inserção e remoção voluntária de um servidor no grupo são bastante simples e envolvem a comunicação apenas entre o servidor alvo da acção e outro servidor que pertença ao grupo de replicadores do volume. Este 4 Uma aproximação alternativa consiste em utilizar identificadores globais dos servidores. Assim, não é necessário actu- alizar os identificadores quando uma nova vista é instalada, mas o espaço ocupado por estes é consideravelmente maior e a implementação e comparação dos vectores versão mais complexa
6.2. SERVIDORES 87 segundo servidor designa-se por patrocinador. Protocolo de entrada no grupo de replicadores Para um servidor iniciar a replicação de um volume é necessário actualizar a informação relativa ao grupo de replicadores do volume e transferir uma cópia do volume para o novo servidor. O protocolo de entrada no grupo de replicadores, detalhado no apêndice A.1.3, é iniciado pelo servidor que pretende iniciar a replicação do volume. Este servidor contacta o patrocinador informando-o da sua intenção. O patrocinador executa a operação de inserção respectiva no coobjecto de filiação e actualiza a réplica do volume usando o protocolo local de mudança de vista. Finalmente, o patrocinador propaga para o novo servidor, no âmbito de uma sessão de sincronização epidémica, uma cópia do volume, incluindo todos os coobjectos. Protocolo de saída do grupo de replicadores Quando um servidor cessa voluntariamente a replicação de um volume é necessário que não se perca nenhuma informação que se encontre apenas nesse servidor (i.e., operações relativas a coobjectos do volume, incluindo o coobjecto de filiação, que apenas sejam conhecidas nesse servidor). Adicionalmente, a filiação do grupo de replicadores deve ser actualizada e os recursos usados para replicar esse volume devem ser libertos. O protocolo de saída do grupo de replicadores de um volume, detalhado no apêndice A.1.4, é ini- ciado pelo servidor i que pretende cessar a replicação do volume. Este servidor coloca-se no estado de pré-removido e não executa mais operações relativas a esse volume. Neste momento, todos os coobjec- tos do volume são notificados que o servidor cessará a replicação do volume 5 . O servidor i informa o patrocinador da sua intenção, o qual notifica a réplica local de todos os coobjectos do volume desse facto. De seguida, o patrocinador estabelece uma sessão de sincronização com o servidor i. No fim da sessão de sincronização, o patrocinador executa a operação de remoção respectiva no coobjecto de filiação e actualiza a réplica do volume usando o protocolo local de mudança de vista. Após executar todas as acções relativas à sessão de sincronização, o servidor i pode libertar os recursos relativos ao volume. Eliminação dos identificadores dos servidores removidos Como os identificadores dos servidores nas vistas são usados na identificação das operações, não é possível eliminar imediatamente o identifi- cador associado a um servidor removido. Este identificador apenas pode ser eliminado quando não for necessário no funcionamento dos coobjectos — ou seja, quando as operações executadas no servidor removido tiverem sido propagadas e definitivamente processadas em todos os servidores. 5 Esta informação é importante em algumas soluções de gestão de dados, como ficou patente na discussão da secção 4.1, relativa ao componente de reconciliação.
- 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 and 72: 4.1. RECONCILIAÇÃO 53 Segundo, um
- Page 73 and 74: 4.1. RECONCILIAÇÃO 55 4.1.3 Ordem
- 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: 6.2. SERVIDORES 85 global a associa
- 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
- Page 123 and 124: 7.1. MODELO GERAL 105 encomenda de
- Page 125 and 126: 7.2. ARQUITECTURA 107 BD réplica C
- Page 127 and 128: 7.2. ARQUITECTURA 109 O subsistema
- Page 129 and 130: 7.3. TRANSACÇÕES MÓVEIS 111 7.3
- Page 131 and 132: 7.3. TRANSACÇÕES MÓVEIS 113 abor
- Page 133 and 134: Capítulo 8 Reservas Neste capítul
- Page 135 and 136: 8.1. TIPOS DE RESERVAS 117 8.1.4 Re
- Page 137 and 138: 8.2. CONCESSÃO E GARANTIA DE RESPE
- Page 139 and 140: 8.2. CONCESSÃO E GARANTIA DE RESPE
- Page 141 and 142: 8.3. PROCESSAMENTO DAS TRANSACÇÕE
- Page 143 and 144: 8.4. PROCESSAMENTO DAS TRANSACÇÕE
- Page 145 and 146: 8.5. EXEMPLOS 127 id tipo tabela co
- Page 147 and 148: 8.5. EXEMPLOS 129 1 ------ COMPRA 1
- Page 149 and 150: Capítulo 9 Avaliação do modelo b
- Page 151 and 152: 9.1. APLICAÇÕES 133 1 ------ REMO
- Page 153 and 154: 9.2. RESERVAS 135 dentemente em dif
86 CAPÍTULO 6. NÚCLEO DO SISTEMA DOORS<br />
De seguida, <strong>de</strong>screve-se o funcionamento do sist<strong>em</strong>a <strong>de</strong> filiação impl<strong>em</strong>entado no sist<strong>em</strong>a DOORS.<br />
Nesta <strong>de</strong>scrição, indicam-se as acções a executar pelos servidores no âmbito da <strong>gestão</strong> <strong>de</strong> filiação <strong>de</strong> um<br />
dado volume, sendo que a <strong>gestão</strong> da filiação <strong>de</strong> cada volume é executada <strong>de</strong> forma in<strong>de</strong>pen<strong>de</strong>nte.<br />
Coobjecto <strong>de</strong> filiação Em cada volume, a informação sobre o grupo <strong>de</strong> servidores que replica o volume<br />
é mantida num coobjecto especial manipulado pelo sist<strong>em</strong>a, o coobjecto <strong>de</strong> filiação. Este coobjecto <strong>de</strong>-<br />
fine três operações <strong>de</strong> modificação: inserção <strong>de</strong> um novo servidor; r<strong>em</strong>oção <strong>de</strong> um servidor; e eliminação<br />
das referências relativas a um servidor anteriormente r<strong>em</strong>ovido.<br />
O estado do coobjecto <strong>de</strong> filiação <strong>de</strong>fine, <strong>em</strong> cada momento, uma vista (view) do grupo <strong>de</strong> replica-<br />
dores do volume que inclui: um i<strong>de</strong>ntificador da vista; a i<strong>de</strong>ntificação do conjunto <strong>de</strong> replicadores; e<br />
uma função bijectiva que atribui a cada replicador do volume um número inteiro, srvview, que o i<strong>de</strong>nti-<br />
fica na vista. Este i<strong>de</strong>ntificador (srvview) é usado na i<strong>de</strong>ntificação das operações, como se explicou na<br />
secção 4.1.1.<br />
Como se <strong>de</strong>talha no apêndice A.1.1, o funcionamento <strong>de</strong>ste coobjecto garante que duas cópias que<br />
tenham conhecimento do mesmo conjunto <strong>de</strong> operações têm o mesmo estado (i.e., estão na mesma vista).<br />
Adicionalmente, garante-se que o i<strong>de</strong>ntificador da vista a i<strong>de</strong>ntifica univocamente, i.e., a cada conjunto <strong>de</strong><br />
operações correspon<strong>de</strong> um e um só i<strong>de</strong>ntificador e a cada i<strong>de</strong>ntificador correspon<strong>de</strong> um e um só conjunto<br />
<strong>de</strong> operações.<br />
Protocolo local <strong>de</strong> mudança <strong>de</strong> vista Como se referiu anteriormente, as operações executadas <strong>em</strong><br />
qualquer coobjecto <strong>de</strong> um volume são i<strong>de</strong>ntificadas com um par que inclui o i<strong>de</strong>ntificador do servidor<br />
na vista. Os sumários <strong>de</strong> operações mantidos são igualmente baseados nestes i<strong>de</strong>ntificadores. Assim, é<br />
necessário actualizar estes i<strong>de</strong>ntificadores s<strong>em</strong>pre que se instala uma nova vista. Para tal, <strong>de</strong>finiu-se o<br />
protocolo local <strong>de</strong> mudança <strong>de</strong> vista, <strong>de</strong>talhado no apêndice A.1.2.<br />
Este protocolo actualiza, <strong>de</strong> forma atómica, todos os coobjectos <strong>de</strong> um volume. O modo como o<br />
coobjecto <strong>de</strong> filiação é actualizado leva a que apenas sejam necessárias actualizações quando se verificam<br />
duas ou mais inserções concorrentes (e <strong>em</strong> que aos novos servidores foram atribuídos, na execução<br />
optimista, o mesmo i<strong>de</strong>ntificador <strong>em</strong> diferentes cópias do mesmo volume) ou uma inserção concorrente<br />
com uma eliminação (<strong>em</strong> que o novo servidor po<strong>de</strong> reutilizar o i<strong>de</strong>ntificador do servidor eliminado) 4 .<br />
Com base no coobjecto <strong>de</strong> filiação e no protocolo local <strong>de</strong> mudança <strong>de</strong> vista, os protocolos <strong>de</strong> inserção<br />
e r<strong>em</strong>oção voluntária <strong>de</strong> um servidor no grupo são bastante simples e envolv<strong>em</strong> a comunicação apenas<br />
entre o servidor alvo da acção e outro servidor que pertença ao grupo <strong>de</strong> replicadores do volume. Este<br />
4 Uma aproximação alternativa consiste <strong>em</strong> utilizar i<strong>de</strong>ntificadores globais dos servidores. Assim, não é necessário actu-<br />
alizar os i<strong>de</strong>ntificadores quando uma nova vista é instalada, mas o espaço ocupado por estes é consi<strong>de</strong>ravelmente maior e a<br />
impl<strong>em</strong>entação e comparação dos vectores versão mais complexa