O modelo de transacções móveis PRO-MOTION (Secção 5.5) [Mazumdar & Chrysanthis 1999] permite que as estações móveis efectuem pedidos de dados ao servidor. Tais dados serão entregues à estação móvel sob a forma de Compactos. Estes, para além dos dados pedidos, contêm informação de estado e de acesso aos dados.
Para tentar resolver os possíveis problemas de consistência, no modelo PRO-MOTION permite-se que para além dos itens de dados, também se repliquem algumas restrições. Por exemplo, se na base de dados fixa existe a restrição R então pode ser criada, a nível local, uma sua réplica R’, servindo para a validação dos seus dados durante a desconexão. Deste modo, permite-se que os utilizadores executem as suas transacções com um certo nível de confiança, mesmo quando estão desconectados da rede fixa.
O PRO-MOTION baseia-se no conceito de localização, que consiste basicamente na substituição de restrições distribuídas R por restrições locais Ri, no nodo i, e no seu ajuste automático ao longo
da actualização incremental. Algumas das propriedades mais significativas deste conceito são: − Quando uma transacção local verifica a restrição Ri,num dado nodo i, então não há
necessidade da verificação da restrição global, evitando-se assim alguns atrasos indesejáveis.
− Quando R’i é mais restrita que Ri então a segunda pode ser substituída, localmente,
pela primeira.
− A actualização incremental das condições de uma restrição pode ser feita num nodo numa altura possível, por uma determinada sequência. Não sendo necessárias
transacções distribuídas com longos protocolos de commit, nem mesmo controlo de concorrência distribuída.
Um aspecto importante que deve ser considerado quando se usa o PRO-MOTION, para que não resultem outras inconsistências, é que todas as réplicas de uma dada restrição devem possuir o mesmo valor. Daqui conclui-se que, não se pode fazer a actualização de uma restrição se existir alguma réplica sua, nalguma estação, que naquele momento não esteja conectado com o sistema, ou seja, só se pode alterar uma restrição quando se consegue efectuar essa alteração em todas as suas réplicas no mesmo instante.
7.2.5.
Controlo de Concorrência Optimista
O modelo de transacções móveis baseado no controlo de concorrência optimista [Ahmed et al. 1996], referido em 5.8, recorre ao uso de isolamento de transacções, bem como a relatórios de invalidação e de actualização para facilitar o processamento de transacções locais. Foi ainda referido, que durante o processamento de uma transacção, esta passa por diversos estados (Figura 18). Contudo, também, aqui, o processamento de transacções pode gerar algumas inconsistências. Em [Ahmed et al. 1996] são apresentadas algumas soluções para a resolução de tais inconsistências.
Quando uma estação móvel dá início à execução de uma transacção de actualização, deve enviar o conjunto de operações de escrita e de leitura para a ESM, de modo a que seja possível efectuar uma validação remota. Neste modelo, a transacção possui apenas um ponto de commit, que é efectuado pelo seu coordenador. A validação da transacção é feita pela certificação de todas as operações que contém, tanto de leitura como de escrita, em todos os servidores. Se todas as operações forem válidas, então faz-se o commit de todas as operações de escrita, caso contrário a transacção é abortada.
Por outro lado, também para se assegurar a consistência dos itens de dados replicados, cada réplica possui ainda um identificador de versão. Este identificador contém uma etiqueta temporal, com a indicação da transacção que actualizou aquele item de dados. Por este motivo, este identificador é considerado um factor chave na fase de validação de uma transacção. Quando uma transacção manipula um item de dados desactualizado o seu processamento é abortado, sendo reiniciado logo de seguida, sem que haja qualquer tempo de espera.
Após o processo de validação, quando uma ESM verifica que uma transacção não é válida, deve então enviar um relatório de invalidação, para todas as estações da sua célula. Estes relatórios incluem todos os itens de dados que foram actualizados, desde o último relatório, bem como a invalidação de outros itens de dados guardados nas estações móveis. Contudo, os relatórios de invalidação não possuem os valores dos dados, mas sim os seus identificadores, de modo a economizar a largura de banda.
O modelo proposto pode ser facilmente adaptado, de forma a suportar consistência fraca, de modo idêntico ao que acontecia no modelo de clustering. Todavia, aceitar que se efectuem operações sobre dados pouco consistentes, implica que se aceite uma divergência nos itens de dados usados a partir do seu valor correcto. Assim, deve existir um critério de divergência, que se baseia no valor correcto do item de dados. Uma divergência de tempo pode ser facilmente mapeada para um valor de divergência de uma etiqueta temporal de uma operação de escrita. Esta etiqueta pode ser incluída nos relatórios de invalidação com um pequeno overhead. Aqui, a divergência pode ser registada de uma das seguintes formas:
− A ESM guarda o trajecto efectuado, por cada estação móvel, fazendo também o registo dos critérios de divergência.
− A estação móvel envia o critério de divergência de cada um dos seus itens de dados.
Logo que se recebe um item de dados através dos relatórios de invalidação, que invalidem uma transacção, a ESM deve ler esses dados de modo a verificar se a transacção é verdadeiramente inválida. Se o servidor mantiver o trajecto de subscrição da vista materializada, é suficiente para se enviar uma mensagem a ignorar o critério de divergência, que ainda não está a ser violado, o que diminui o broadcast. Se um item de dados for materializado, a estação móvel tem a opção de esperar pelo próximo relatório de actualização, que deve conter o valor do item de dados que se suspeita estar inválido.
7.2.6.
HiCoMo
O modelo de transacções HiCoMo [Lee & Helal 2002], apresentado em 5.11, tem como principal objectivo maximizar, o mais possível, o número de commits das transacções. Este objectivo é conseguido através do relaxamento de algumas condições. Contudo, deve existir um certo
controlo sobre os dados actualizados pelas transacções, para que se evitem eventuais inconsistências.
Para manter a consistência dos dados, este modelo de transacções, tem por base o seguinte algoritmo:
− Detecção de conflitos. Primeiramente, devem ser detectados os conflitos entre uma transacção HiCoMo e outras transacções HiCoMo, que ainda não tenham sido transformadas em transacções base. Se se detectar um conflito aborta-se a transacção HiCoMo que está a ser considerada para a transformação. A simples estratégia de aborto deve-se ao facto de, neste modelo, se pretender fornecer durabilidade às transacções base, para além de que não existe uma forma de controlar o que se passa dentro de outras transacções base. A detecção de conflitos pode ser implementada por uma estratégia de controlo de concorrência optimista (Secção 5.8). Com esta estratégia, uma transacção passa por três fases: execução, validação e actualização. Aqui, a fase de execução é processada quando as transacções HiCoMo executam actualizações nas tabelas agregadas na estação móvel. Os autores consideram que esta fase se inicia com a desconexão e acaba quando a estação se volta a conectar. Durante a fase de validação é verificada a existência, de eventuais, conflitos das actualizações locais com as actualizações efectuadas por outras transacções. Se as alterações da transacção HiCoMo forem mais recentes do que as das transacções base, então permite-se que as alterações sejam aplicadas às tabelas base, caso contrário são abortadas. Esta fase de validação começa quando a estação se reconecta à rede fixa. Por último, a fase de actualização consiste na transformação das transacções HiCoMo em transacções base, aplicando-as, de seguida, às tabelas base. Com o uso desta estratégia, as transacções ficam seriadas pela mesma ordem das etiquetas temporais. − Geração da transacção base inicial. Se não existirem conflitos decide-se que tipo de
transacção base deve ser criada. Esta decisão baseia-se em informação dada pela transacção HiCoMo, bem como por factores das funções de agregação e das tabelas. De seguida, as transacções são executadas como subtransacções de um modelo de transacções nested estendido.
− Falha da subtransacção e geração da transacção base alternativa. Algumas das subtransacções geradas podem abortar por violarem as restrições de integridade. Como estas situações são difíceis de prever antes da execução, as transacções abortadas
necessitam de ser renegociadas posteriormente. As subtransacções abortadas afectarão todos os resultados das transacções HiCoMo e precisam de ser compensadas de alguma forma. Se a diferença que as subtransacções abortadas provocam se encontrar dentro da margem de erro permitida, então a transacção pode terminar o seu processamento. Caso contrário, as actualizações das transacções abortadas devem ser redistribuídas e tentar uma nova execução. Se depois de algumas redistribuições a transacção continuar a abortar, então também se deve ter em conta a margem de erro nessa redistribuição. A transformação está completa quando as subtransacções conseguirem obter sucesso nalgum ponto, se não o conseguirem, a transacção HiCoMo deve ser abortada.