As Transacções Canguru representam outro modelo para transacções móveis [Dunham et al. 1997] [Dunham & Kumar 1999]. Este modelo dá especial atenção ao facto das transacções nos ambientes móveis mudarem muitas vezes de célula, e, consequentemente, possuírem saltos frequentes de uma ESM para outra. Por este motivo, designam-se estas transacções móveis por transacções Canguru.
Na definição de uma transacção Canguru deve-se ter em conta o conceito de transacção global. Esta consiste numa sequência de transacções, que pode incluir outras transacções globais (Figura 16). Neste modelo considera-se ainda o conceito de transacção joey (TJ), que consiste numa sequência de zero ou mais transacções usuais ou globais, seguidas de uma operação de um commit, um aborto ou uma troca.
Transacção Global
Transacção 1 Tr. Global 2
Tr. Global 1
Figura 16 – Vista de uma transacção global.
O modelo de transacções Canguru considera a existência de uma arquitectura baseada em agentes. Assim, quando é feito um pedido de transacção, por uma estação móvel, o agente da ESM correspondente deve criar uma transacção móvel (Canguru) para realizar o pedido, associando-lhe um identificador. As transacções móveis são constituídas por um conjunto de subtransacções. Cada subtransacção representa uma unidade de execução numa ESM, que é designada por transacção joey. Assim, pode-se definir uma Transacção Canguru como uma sequência de uma ou mais transacções joey (Figura 17). A última transacção joey da sequência deve acabar num commit ou num aborto, enquanto que as restantes devem terminar com uma operação de troca. À sequência de transacções locais e globais que são executadas numa dada transacção Canguru dá-se o nome de pouch.
Tr. Joey 1 Tr. Global 1 Tr. Global 2 Transacção 1 Tr. Canguru Tr. Joey 2 Tr. Global 3 Tr. Global 4 Tr. Joey 3 Tr. Global 5
Figura 17 – Exemplo de decomposição de transacção Canguru.
Quando uma estação móvel salta de uma célula para a outra, o controlo da transacção Canguru deve passar para a nova célula, tendo assim um novo agente de acesso aos dados. Nesta altura,
é criada uma nova transacção joey que é acompanhada por uma operação de troca, enquanto que a transacção antiga é guardada independentemente da nova. Só se cria uma nova transacção joey quando há uma mudança de célula. Isto faz com que, a mesma transacção, pedida em diferentes alturas, possa possuir diferentes estruturas. Diz-se que duas transacções Canguru são equivalentes quando possuem o mesmo pouch.
Para gerir a execução e a recuperação de uma transacção Canguru mantém-se uma lista duplamente ligada com todas as ESMs envolvidas na sua execução. Para finalizar uma transacção Canguru que se encontrava parcialmente completa deve-se atravessar essa lista em modo forward, começando na ESM que a originou. Assim, para recomeçar uma transacção interrompida, o utilizador deve ser capaz de indicar a estação onde se iniciou a transacção. Quando se pretende desfazer uma transacção Canguru essa lista deve ser percorrida em sentido contrário. As transacções Canguru têm os seguintes modos de processamento:
− Modo de compensação31. Quando uma transacção se encontra neste modo, uma falha da transacção joey obriga a que todas as outras transacções joey, anteriores ou posteriores, sejam desfeitas. Deste modo, os commits das transacções joey precedentes devem ser compensados, sendo o próprio utilizador, ou sistema origem, quem deve fornecer a informação necessária para construir as transacções de compensação. O sistema não deve apenas garantir que as transacções joey são compensadas, como deve, também, garantir que o commit das transacções de compensação se efectua com sucesso.
− Modo de troca32. As transacções são executadas por defeito neste modo de operação. Neste caso, quando uma transacção joey falha, não são pedidas, por parte da transacção Canguru, quaisquer novas transacções locais ou globais. Ficando a cargo do SGBDM decidir se deve ou não abortar as transacções joey que se encontram a executar. As transacções joey precedentes, que fizeram commit não necessitam de ser compensadas.
Nenhum destes modos de operação garante a seriação das transacções Canguru. O modo de compensação assegura a atomicidade das transacções, mas viola a propriedade de isolamento33,
31 Compensating mode. 32
Split mode.
já que os locks são obtidos e mantidos a nível local da transacção. Contudo, com este modo de operação, as transacções são seriáveis.
Neste modelo de transacções móveis, a gestão das transacções é feita com base em duas tabelas: a de estado e a de logs. A tabela de estados (Tabela 1) contém a informação dos estados de todas as transacções que se encontram a executar. Por sua vez, a tabela de logs (Tabela 2), que cada ESM deve conter, possui registos que serão necessários para eventuais processos de recuperação. A maioria destes registos está relacionada com entradas da tabela de estados. Em conclusão, o modelo de transacções móveis baseado nas transacções Canguru capta tanto o comportamento dos dados como também o seu movimento, incorporando para tal a propriedade saltitante das transacções móveis. Como se sabe, o comportamento móvel é dinâmico e é conseguido neste modelo através das operações de troca. O comportamento de acesso aos dados é capturado através do uso de transacções locais e globais. Este modelo fornece, ainda, a facilidade de lidar tanto com transacções curtas como com transacções mais longas.
Tipo de Registo Atributos Descrição
KT KTID Modo Contador de TJ Estado FirstJTID
Identificador para uma transacção Canguru Troca ou compensação
Número de TJs activas na transacção Canguru actual Activa, commiting, aborting
Apontador para o primeiro registo de estado de TJ nesta Transacção Canguru JT JTID NextJTID PriorJTID Estado STList Compensável ID para a TJ
Apontador para o próximo registo de estado da TJ Apontador para o registo de estado anterior da TJ Activo, Commit ou Aborto
Lista de transacções locais e globais Sim/Não ST STID Estado Pedido Compensável CompTR ID da subtransacção Activo, Commit ou Aborto
Pedido de transacção local ou global Sim/Não
Transacção de Compensação
Tipo de Registo Conteúdo
BTKT KTID, Modo CTKT KTID, Modo BTJT JTID, Prior JTID
BTST STID, Pedido, Compensação ETJT JTID, Próximo JTID
ETST STID ETKT KTID HOKT KTID
Tabela 2 – Exemplo de uma tabela com registos de log.