Modelo de Transação com Replicação em two-tier (duas-fileiras)

O modelo de replicação two-tier assume dois tipos de nós (unidades): nós móveis que estão desconectados parte do tempo e nós base, que estão sempre conectados. Os nós móveis armazenam uma réplica do banco de dados e podem originar transações tentativas; um nó móvel pode ser o mestre de alguns ítens de dados.

Nós base armazenam uma réplica do banco de dados. A maioria dos ítens de dados são mestres de nós base.

Segundo GRAY et al (1996), os nós móveis têm duas versões de ítens de dados: versão mestre e versão tentativa. Versão mestre é o valor mais recente recebido do objeto mestre. A versão do objeto mestre é a versão de mestre. Porém, quando os nós estão desconectados ou com réplicas relaxadas podem ter versões mais velhas.

Versão tentativa: é criada com o valor mais recente devido a atualizações locais, esta é mantida como um valor tentativo. O objeto local pode ser atualizado por meio de transações tentativas. Este modelo suporta dois tipos de transações: básicas e tentativas. As transações básicas são executadas acessando versões mestre do dado (esquema de replicação mestre-lazy), e transações tentativas são executadas acessando versões tentativas (cópias locais). Transações tentativas podem executar atualizações na unidade móvel no modo desconectado.

Transação tentativa: trabalham em modo desconectado, lêem dados mestres e produzem dados tentativos locais. A transações tentativas poderão ser convertidas em transações básicas quando houver a conexão com os nós base. Transações tentativas têm que seguir uma regra de escopo: eles podem envolver objetos mestres em nós base e objeto mestre em nós móvel e podem originar uma transação (transações escopo). A idéia é que o nó móvel e todos os nós base entrarão em contato quando a transação tentativa é processada como uma transação básica realmente. Assim uma transação real poderá ler a cópia de mestre de cada item de dado no escopo.

A transação básica gerada por uma transação tentativa pode falhar ou pode produzir resultados diferentes. A transação básica tem um critério de aceitação: um teste resultante das output têm que passar por uma ligeira diferença do resultado da transação básica para ser aceitável.

Se uma transação tentativa falhar, o nó que originou e a pessoa que gerou a transação são informados da falha e por que falhou. Aceitação de falha é equivalente ao mecanismo de reconciliação dos esquemas de replicação de lazy-group (grupo relaxado). As diferenças são: (1) o banco de dados do mestre sempre é convergido—não há nenhuma ilusão de sistema; e (2) o nó que originou somente deve contactar um nó base para descobrir se uma transação tentativa é aceitável.

Conforme GRAY et al (1996), considerando o caso desconectado, se um nó móvel desconectou um dia atrás, ele terá uma cópia base dos dados a partir de ontem. Gerou

55 transações tentativas naqueles dados base e nos dados locais da cópia mestre utilizada pelo nó móvel. Estas transações geraram versões de dados tentativas no nó móvel. Essas atualizações tentativas são todas visíveis ao nó móvel.

Quando um nó móvel conecta a um nó base, o nó móvel:

1. descarta suas versões de objeto tentativas desde que eles sejam refreshed dos mestres;

2. envia atualizações de réplica para qualquer objeto mestre, tanto para o nó móvel quanto para o nó base;

3. envia todas suas transações tentativas (e todos seus parâmetros de input) para o nó base para ser executado na ordem na qual eles consolidaram no nó móvel;

4. aceita atualizações de réplica do nó base (este é o padrão de replicação do mestre relaxado), e

5. aceita notificação do sucesso ou fracasso de cada transação tentativa.

O nó base é a outra classe das duas classes. Quando contatado por uma nota móvel, o nó base:

1. envia transações de atualização de réplica atrasadas ao nó móvel;

2. concorda com atualizações atrasadas de transações para objetos móvel-mestre do nó móvel;

3. aceita a lista de transações tentativas, as suas mensagens de entrada e seus critérios de aceitação. Reprisa cada transação tentativa na ordem em que consolidou no nó móvel. Durante este re-processamento, a transação básica lê e escreve cópias de mestre do objeto que usa um modelo de execução de mestre- relaxado. A regra do escopo assegura que a transação básica só acessa dados mestres originado do nó móvel e do nó base. Assim, cópias de mestre de todos os dados na transação escopo estão disponíveis à transação básica. Se fracassar os critérios de aceitação da transação básica, esta é abortada e uma mensagem diagnóstico é devolvida ao nó móvel. Se os critérios de aceitação requerem que a transação básica e a tentativa tenham saídas idênticas, então transações subseqüentes que lêem resultados tentativos escritos por T também falharão. Por outro lado, ps critérios de aceitação da transação mais fraca é possível;

4. depois que o nó base consolida uma transação básica, ele propaga a réplica desta transação atualizada relaxada e envia a todos os outros nós à réplica. Este é o padrão mestre-ralaxado;

5. Quando todas as transações tentativas forem re-processadas como transações básicas, o estado do nó móvel é convergido com o estado básico. Figura 4.5

Transação Tentativa do Nó Móvel

Transações de outros Envio de Transação Tentativa

Figura 5.5- Execução de Transações Tentativas e Base em Replicação Two-tier Fonte: GRAY et al (1996)

As propriedades fundamentais do esquema de replicação two-tier são: 1. nós móveis podem fazer atualizações de banco de dados tentativas;

2. transações básicas executam através de única-cópia a serializabilidade, assim o estado do sistema base mestre é o resultado de uma execução de serializabilidade;

3. uma transação fica durável quando a transação básica completar;

4. réplicas de todos os nós conectados convergem com o estado de sistema básico; 5. se todas as transações comutam, não há nenhuma reconciliação.

A taxa de reconciliação para transações básicas será zero se toda as transações comutarem. A taxa de reconciliação é dirigida pela taxa à qual as transações básicas falharam quanto aos critérios de aceitação. O processamento da transação básica pode produzir resultados diferentes dos resultados tentativos. Isto é aceitável para algumas aplicações.

Ambos, clustering e replicação de two-tier requerem um gerente de transação na unidade móvel para prover a execução da transação local, controle de concorrência, gerenciamento de log e recuperação.

57 Se a transação tentativa completa prosperamente e passa no teste de aceitação, então o sistema de replicação assume que tudo está bem e propagam as réplicas atualizadas. Os usuários estão cientes que todas as atualizações são tentativas até que a transação se torna uma transação básica. Se a transação básica falhar, o usuário pode ter que revisar e re-submeter uma transação. O programador deve projetar as transações para ser comutativas e ter critérios de aceitação para descobrir se a transação tentativa concorda com os efeitos de transação básicos.