O modelo de transacções aqui apresentado [Gray et al. 1996] supõe a existência de um modelo de replicação a dois níveis (Secção 4.3), no qual um dos níveis é representado pelas estações móveis e outro pelas ESMs. As estações móveis guardam as cópias dos fragmentos da base de dados e executam as tarefas locais sobre elas, produzindo dados que se designam de tentativos e que, posteriormente, devem ser validados de modo a que se tornem dados definitivos. Quando as estações móveis se conectam à rede fixa podem propor transacções de actualização tentativas à estação que contém a réplica mestre. Esta, por sua vez, deve reexecutar todas as transacções que a estação móvel executou durante a desconexão. Se estas terminarem com sucesso então são tornadas definitivas. Caso contrário são rejeitadas. Porém, as transacções tentativas rejeitadas devem ser reconciliadas pela estação móvel que as gerou. Depois das trocas de informação, as estações móveis devem encontrar-se sincronizadas com as estações fixas. O sistema a dois níveis opera como um sistema Lazy-Master, mas com a restrição de que nenhuma transacção pode actualizar dados que tenham as cópias mestre em mais do que uma estação móvel, não sendo esta restrição verdadeiramente necessária quando as estações se encontrem conectadas.
O sistema a dois níveis opera como um sistema lazy-master, mas com a restrição de que nenhuma transacção pode actualizar dados que tenham as cópias mestre em mais do que uma estação móvel, não sendo esta restrição verdadeiramente necessária quando as estações se encontrem conectadas.
Nas estações móveis, os itens de dados replicados possuem duas versões: a mestre e a tentativa. A versão mestre de um item de dados corresponde ao último valor recebido da estação que possui a sua cópia mestre. As estações que contêm a cópia mestre possuem sempre a sua versão mestre, cujo valor pode coincidir ou não com o das restantes réplicas. De modo semelhante, podem-se identificar dois tipos de transacções: as base e as tentativas. As transacções base trabalham apenas sobre dados mestre, originando, obviamente, dados mestre. Por sua vez, as transacções tentativas trabalham apenas sobre os dados locais e, como o próprio nome indica, produzem versões tentativas dos dados. Sempre que executa uma transacção tentativa produz-se uma transacção base, que deve ser executada nas ESMs quando se restabelecer a conexão. Deste modo, as actualizações que foram executadas localmente podem ser executadas globalmente.
Uma transacção base gerada por uma transacção tentativa pode falhar ou produzir resultados diferentes dos obtidos pela transacção tentativa. Para isso, as transacções base possuem um critério de aceitação que testa os resultados de saída. Quando uma destas transacções falha, deve-se notificar a estação que a iniciou, indicando-se ainda os motivos da falha. Uma falha de aceitação é equivalente aos mecanismos de reconciliação dos esquemas de replicação lazy- group, com as diferenças de que:
− A base de dados mestre está sempre convergente – não existe delusion do sistema. − A estação originária necessita apenas de contactar a ESM de forma a descobrir se a
transacção tentativa é aceitável.
O critério de aceitação é específico às aplicações. O sistema de replicação não pode fazer mais do que detectar as diferenças entre os valores da transacção tentativa e os da base, o que provavelmente pode ser um teste muito pessimista. Assim, o sistema de replicação executa, simplesmente, as transacções tentativas. Se estas terminam com sucesso e satisfazem o teste de aceitação, então o sistema de replicação assume que tudo correu bem, propagando as actualizações pelas restantes réplicas. Caso contrário, o utilizador móvel deve rever e resubmeter essa transacção.
Deste modo, com o uso deste modelo de transacções, sempre que a estação móvel se conecte à ESM deve:
− Descartar as versões dos objectos tentativas, pois estas serão actualizadas pelas versões mestres.
− Enviar para a ESM as actualizações que efectuou nas réplicas mestre que possui, pois só assim é que estas podem visualizadas pelas restantes estações que pretendem aceder a estes dados.
− Enviar todas as suas transacções tentativas (e todos os seus parâmetros de entrada) para a ESM, de modo a que sejam executadas pela mesma ordem com que foram guardadas localmente.
− Aceitar a actualização de réplicas que a ESM indicar.
− Aceitar a notificação do sucesso ou falha das transacções tentativas que enviou.
Por sua vez, a ESM, que é o outro nível deste modelo, quando se encontra conectada com a estação móvel, deve:
− Enviar para outras estações, as transacções de actualização contendo os itens de dados actualizados pela estação móvel.
− Aceitar as transacções atrasadas de actualização de objectos, dos quais a estação móvel possui a réplica mestre.
− Aceitar a lista de transacções tentativas, as suas mensagens de entrada e o seu critério de aceitação.
− Reexecutar as transacções tentativas pela mesma ordem com que foram executadas na estação móvel.
− Propagar as actualizações para todas as outras réplicas (seguindo um modelo lazy- master) depois de ter guardado a transacção base.
As transacções tentativas devem ser desenhadas de modo a que possam comutar com outras transacções, na esperança de se aumentar a probabilidade de sucesso. As transacções tentativas devem acompanhar a seguinte regra de scope: podem envolver objectos de dados que possuem a versão mestre nas estações fixas e outros que possuem as versões mestre na estação móvel que originou a transacção. O objectivo é dar a ideia de que a estação móvel está conectada com as estações fixas durante a execução das transacções tentativas. Basicamente, deve dar-se a ideia de que estas transacções são executadas como verdadeiras transacções base. A regra de scope assegura que a transacção base apenas acede a dados mestre da estação móvel originária e das estações base.
Se a transacção base falhar o processo de aceitação deve ser abortado, sendo enviada uma mensagem de diagnóstico à estação móvel. Se o critério de aceitação requeria que as transacções base e tentativas tivessem valores de saída semelhantes, então as transacções subsequentes ao lerem esses resultados tentativos também devem falhar. No entanto, podem ser usados critérios de aceitação mais fracos. Quando todas as transacções tentativas são re- processadas como transacções base, o estado da estação móvel converge para o estado da ESM. [Liu et al.1999] defendem que este modelo de transacções, usando a replicação a dois níveis, pode causar um grande overhead de reprocessamento na cópia mestre e sugerem que se acrescente, a este modelo, alguma semântica que tente evitar esse overhead. Para tal, usam um método de junção de histórias das transacções que substitui o reprocessamento que ocorre neste modelo. Deste modo, sempre que uma estação móvel se conecta à rede fixa faz-se a junção das histórias tentativas e das histórias base, podendo assim ser aproveitada uma grande quantidade do trabalho das transacções tentativas. De modo semelhante à classificação das transacções, diz- se que se trata de uma história tentativa quando se trata da história de execução de transacções tentativas, iniciadas e executadas nas estações móveis. Por sua vez, uma história diz-se base, quando corresponde à história de execução das transacções base, que lêem e escrevem sobre dados mestre.
Quando duas histórias entram em conflito constrói-se um grafo de precedências para se detectarem as inconsistências e para se calcular o conjunto de transacções que as causou. Estas, quando são retiradas ou remodeladas, podem resolver os conflitos, rescrevendo a história das transacções. O processo de retirar essas transacções indesejáveis pode ser bastante complexo porque podem afectar outras transacções. Em [Liu et al.1999] propõem-se alguns algoritmos de rescrita das histórias das transacções. Este modelo de transacções mantém os aspectos positivos do modelo de transacções de replicação a dois níveis, tentando evitar alguns dos problemas que
aí surgem, como o overhead de reprocessamento. Além disto, a propriedade de durabilidade das transacções não é violada.