A necessidade de identificar unicamente os registros ´e uma caracter´ıstica presente na maior parte dos sistema de informa¸c˜ao. Conforme visto na Se¸c˜ao 3.7, o car´ater distribu´ıdo das solu¸c˜oes de mobilidade imp˜oe um grande desafio na tarefa de gerar identificadores que sejam ´
unicos, evitando o problema de colis˜ao de chaves prim´arias, e, ao mesmo tempo, compactos,
evitando que as opera¸c˜oes de acesso a dados sejam afetadas negativamente. O framework mSync prop˜oe um esquema para gera¸c˜ao de identificadores que atende a estes dois objetivos e, por isto, ´e mais eficiente do que as alternativas propostas por outras arquiteturas, como o SyncML (SyncML Protocol (2001)) e Microsoft Sync Service (MicrosoftSyncServices (2008)), apresentadas na Se¸c˜ao 3.7.
As tabelas sincronizadas por meio do framework mSync devem possuir um campo utilizado
para identificar unicamente cada registro. Este campo ´e conhecido como chave prim´aria ou
primary key (Vieira (2007)). Quando um registro ´e inserido na base de dados local de um dispositivo, o framework se encarrega de atribuir ao identificador do registro um valor que seja ´unico localmente (LUID). Durante a sincroniza¸c˜ao, quando o registro ´e inserido na base de dados central, ele recebe um identificador global (GUID), que ´e gerado pelo banco de dados central. No final da sincroniza¸c˜ao, o identificador local no dispositivo ´e substitu´ıdo pelo identificador global definitivo, que foi gerado no servidor.
O mSync trata as quest˜oes relacionadas `a gera¸c˜ao dos LUIDs e GUIDs, escondendo dos
programadores a complexidade envolvida no processo. O LUID deve ser ´unico localmente, o
que significa que n˜ao deve existir, na base de dados local do dispositivo, nenhum outro regis- tro com o mesmo identificador. O procedimento 1 descreve a regra utilizada pelo framework para gerar os identificadores locais.
————————————————————————————————
Procedimento 1-Regra utilizada para gerar os identificadores ´unicos locais
————————————————————————————————
Se max(Identif icador) > 900.000.000 ent˜ao
N ovoIdentif icador = max(Identif icador) + 1
Sen˜ao
N ovoIdentif icador = 900.000.001
Fim Se
————————————————————————————————
Este processo garante que o valor do LUID ser´a sempre ´unico localmente. A constante
900.000.000, utilizada no procedimento 1, pode ser ajustada, para mais ou para menos, de-
pendendo do valor m´aximo suportado pelo tipo de campo utilizado como chave prim´aria. Em
uma an´alise simples, algu´em poderia sugerir que os identificadores locais fossem gerados por meio do procedimento 2, descrito a seguir:
————————————————————————————————
Procedimento 2-Regra que n˜ao deve ser utilizada para gerar os identificadores ´unicos locais ————————————————————————————————
4. Framework mSync 49
N ovoIdentif icador = max(Identif icador) + 1
————————————————————————————————
O problema com o procedimento 2, que simula um campo do tipo auto-incremental (Vieira (2007)), ´e que, no final do processo de sincroniza¸c˜ao, quando os LUIDs s˜ao substitu´ıdos pelos GUIDs na base de dados local do dispositivo, podem ocorrer colis˜oes entre um GUID defi- nitivo, gerado no servidor, e um LUID provis´orio, que ainda n˜ao foi substitu´ıdo pelo GUID definitivo dentro da mesma sess˜ao de sincroniza¸c˜ao. A classe do framework respons´avel pela gera¸c˜ao do LUID ´e a ClientSyncDAO, que ser´a detalhada na Se¸c˜ao 4.5.5.
No banco de dados central s˜ao utilizados campos do tipo auto-incremental para as chaves
prim´arias. Com isto, quando um registro ´e inserido no banco de dados central, o pr´oprio
banco de dados se encarrega de criar um identificador ´unico global para a linha.
Durante a sincroniza¸c˜ao de dados, os registros inseridos no dispositivo s˜ao aplicados no servidor e os GUIDs gerados s˜ao enviados de volta para o dispositivo para que este substitua
cada LUID pelo seu respectivo GUID, de forma que os identificadores ´unicos sejam os mesmos
nas plataformas fixa e m´ovel. O framework se encarrega de, automaticamente, durante a sincroniza¸c˜ao, substituir os LUIDs pelos GUIDs nas tabelas sincronizadas. Por´em, ´e comum que as aplica¸c˜oes utilizem relacionamentos onde o identificador de uma tabela ´e referenciado em outras tabelas. Caso esteja sendo utilizado um banco de dados m´ovel com suporte para
relacionamentos do tipo update cascade (Vieira (2007)), o pr´oprio banco de dados pode se
encarregar de atualizar o identificador do registro nas outras tabelas onde ele ´e utilizado. Por´em, se o banco de dados n˜ao suportar este tipo de relacionamento ou, por algum motivo, ele n˜ao puder ser utilizado, o mSync, ap´os substituir o LUID pelo GUID, dispara um evento (ver Apˆendice A.2.8) no cliente que permite que a aplica¸c˜ao atualize o identificador da tabela sincronizada nas outras tabelas onde ele ´e utilizado.
Tratamento de falhas de conex˜ao
Quando um registro inserido no dispositivo ´e aplicado na base de dados central, se, por algum motivo, a conex˜ao entre o dispositivo e o servidor for interrompida antes que o dispositivo
receba o GUID correspondente ao registro aplicado, o cliente n˜ao ter´a como detectar se o
registro foi ou n˜ao inserido na base de dados central e, na pr´oxima sincroniza¸c˜ao, ir´a enviar o mesmo registro novamente para que ele seja aplicado no servidor. Como n˜ao existe rela¸c˜ao
entre o LUID e o GUID, o servidor n˜ao possui meios para detectar que este registro j´a foi
inserido no banco de dados central, o que, neste caso, faria com que o registro fosse criado em duplicidade.
Para evitar a situa¸c˜ao descrita acima, o mSync utiliza uma tabela de controle para realizar o mapeamento de chaves locais em chaves globais, chamada idMapping, cuja estrutura ´e exibida na figura 4.7.
Os campos da tabela idMapping possuem a seguinte fun¸c˜ao:
idSync: Valor da ˆancora de sincroniza¸c˜ao referente `a tabela e sincroniza¸c˜ao executada pelo dispositivo.
4. Framework mSync 50 idMapping idSync int <pk> codTable int <pk> LUId int <pk> GUId int dtInsert datetime
Figura 4.7: Estrutura da tabela idMapping
codTable: C´odigo da tabela onde o registro foi inserido.
LUId: Identificador ´unico local atribu´ıdo pelo mSync no momento em que o registro foi criado no banco de dados m´ovel.
GUId: Identificador ´unico global gerado no momento em que o registro foi inserido no banco de dados central.
dtInsert: Data em que o registro foi inserido no banco de dados central.
Sempre que um registro ´e inserido no banco de dados central por meio do processo de sincroniza¸c˜ao de dados, o ServerSyncDAO (ver Se¸c˜ao 4.5.11) cria uma linha de controle na tabela idMapping, que ´e utilizada para relacionar o LUID tempor´ario, criado no dispositivo, com o GUID definitivo, criado no servidor.
Antes que qualquer novo registro enviado pelos dispositivos seja inserido no banco de dados central, o ServerSyncDAO verifica, por meio de uma consulta utilizando chave exata (idSync, codTable, LUId), se a linha referente a este registro j´a existe na tabela idMapping. Caso a linha exista, significa que o registro j´a foi inserido no banco de dados central e, por algum motivo, o ´ultimo processo de sincroniza¸c˜ao n˜ao foi totalmente conclu´ıdo, de modo que o dispositivo ainda n˜ao foi notificado da inclus˜ao do registro e o LUID substitu´ıdo pelo GUID no banco de dados local. Nessa situa¸c˜ao, ao inv´es de inserir o registro no banco de dados central, o mesmo ´e atualizado utilizando-se o GUID, referente a esse registro, armazenado na idMapping. Caso a linha n˜ao exista, significa que o registro ´e realmente novo e ele ´e inserido na tabela correspondente do banco de dados central, sendo que, ap´os a inser¸c˜ao, ´e criado um registro de controle na tabela idMapping. A figura 4.8 apresenta um exemplo do processo de convers˜ao de identificadores locais para identificadores globais.
O que garante o funcionamento da t´ecnica proposta ´e o fato da chave da tabela idMapping,
formada pelos campos idSync, codTable e LUId ser ´unica. Isto ocorre porque a forma como
o LUID ´e atribu´ıdo no dispositivo garante que, para uma mesma tabela (codTable) e um mesmo per´ıodo de desconex˜ao (idSync), nunca existir˜ao dois LUIDs coincidentes.