Um fluxo de mensagens pode consistir nas partes constituintes a seguir:
Uma seqüência típica de eventos quando um fluxo de mensagens processa uma mensagem é descrito abaixo:
Observe que esta seqüência de eventos não faz nenhuma distinção entre acessar tabelas e gravar mensagens de saída. Apesar de um fluxo produzir freqüentemente algum tipo de mensagem de saída, não há nenhuma distinção real entre produzir uma mensagem de saída e atualizar uma tabela de banco de dados; em ambos casos, o estado dos dados no sistema é alterado.
=====x=========x===x=======x=============x====x===== 1 2 3 4 5 6
A linha representa os dados no sistema ao longo do tempo. No tempo 1, uma mensagem chega e é extraída da fila de entrada. Nos tempos 2, 3, 4 e 5, os dados são utilizados para atualizar as tabelas do banco de dados ou são gravados nas filas. As alterações no estado dos dados são indicadas no diagrama pelo símbolo x. No tempo 6, as mensagens de saída são enviadas e o sistema está inativo. Entre esses eventos, não há nenhuma alteração no estado dos dados; isso é indicado no diagrama pelo símbolo =.
Se ocorrer uma falha no sistema (por exemplo, uma queda de energia no computador no qual o intermediário está em execução), as alterações de estado de tabelas e filas que foram feitas antes da falha ocorreram, mas não ocorreram mais alterações após a falha. Essa situação é inaceitável em determinadas circunstâncias; por exemplo, se uma falha de sistema ocorrer ao fazer um pagamento de uma conta atual para uma conta de hipoteca, o pagamento pode ser feito da conta atual, mas não é incluído na conta de hipoteca.
-----x=========x===x=======x=============x====x----- 1 2 3 4 5 6
A linha do diagrama representa os dados extras do sistema à medida que o tempo passa. No tempo 1, uma mensagem chega e é extraída da fila de entrada. Antes do tempo 1, não há nenhum dado extra no sistema; isso é indicado no diagrama pelo símbolo -. Após o tempo 1, o estado representa o fato de que uma mensagem foi extraída da fila de forma que possa ser colocada de volta na fila se necessário. Nos tempos 2, 3, 4 e 5, os dados são utilizados para atualizar as tabelas do banco de dados ou são gravados nas filas. Novamente, o estado dos dados extras é alterado, de forma que as alterações das tabelas e filas possam ser desfeitas se necessário. No tempo 6, as mensagens de saída são enviadas, o sistema está inativo e não há dados extras no sistema mais uma vez. Entre esses eventos, não há nenhuma alteração no estado dos dados extras e isso é indicado pelo símbolo =. Se ocorrer uma falha a qualquer tempo entre o tempo 1 e o tempo 6, os dados extras são utilizados para restaurar o estado original dos dados do sistema, portanto, efetivamente, nenhum dados foi gravado nas filas de saída, nenhuma das tabelas foi atualizada e a mensagem de entrada não foi extraída da fila de entrada. Se não ocorrer nenhuma falha, as alterações tornam-se permanentes no tempo 6 (uma operação de desfazimento seguindo uma falha subseqüente não desfará as alterações).
O modo de operação descrito acima é conhecido como modo de transação coordenado. A conclusão bem-sucedida de uma transação é conhecida como sua confirmação. Uma conclusão mal sucedida é conhecida como recuperação.
O recurso-chave do modo de transação coordenada da operação é que, independentemente de onde ou quando aparece uma falha, todas as alterações nas filas e tabelas associadas a uma mensagem de entrada são feitas ou nenhuma das alterações são feitas. No entanto, esse comportamento nem sempre é adequado, conforme ilustrado pelos exemplos a seguir:
MAIN -----x=========x===x=======x=============x====x----- 1 2 4 5 8 9 1o. AUX --------------x======x========x------ 3 6 7
A linha MAIN representa a transação principal, que inclui os dados extras necessários para restaurar o estado original caso seja necessário. A linha 1st AUX representa uma transação auxiliar. No tempo 3, é feita uma atualização em uma tabela ou fila e outra atualização é feita no tempo 6. No tempo 7, o fluxo de mensagens determina que todas as alterações que precisam ser feitas sob a transação auxiliar sejam concluídas e ele confirma as alterações.
Se o fluxo de mensagens falhar antes do tempo 7, o estado do sistema permaneceria inalterado, pois ambas transações seriam recuperadas. Se ocorrer uma falha após o tempo 7, mas antes do tempo 9, a transação auxiliar já teria sido confirmada, mas a transação principal seria recuperada. Se não ocorrer uma falhar até o tempo 9, ambas transações são confirmadas.
Você pode utilizar mais de uma transação auxiliar e fazer várias atualizações nas tabelas de banco de dados que podem ser confirmadas ou recuperadas. Você pode, então, fazer alterações adicionais nas mesmas tabelas de banco de dados ou em diferentes tabelas e, em seguida, confirmar ou recuperar essas alterações.
Cada banco de dados utilizado tem sua própria transação auxiliar, portanto, se o fluxo de mensagens atualizar tabelas pertencentes a diferentes instâncias do banco de dados (diferentes nomes de origens de dados), há uma transação auxiliar para cada banco de dados. Você deve confirmar ou recuperar essas transações individualmente. Quaisquer atualizações que não tenham sido confirmadas nem recuperadas na conclusão da operação (no tempo 9 no exemplo acima) serão confirmadas ou recuperadas automaticamente pelo intermediário, de acordo com que se o processamento foi bem-sucedido ou falhou.
Alguns tipos de bancos de dados, como o DB2 no AIX, não permitem transações coordenadas e não coordenadas na mesma instância do banco de dados. Nesses casos, você deve criar instâncias de banco de dados separadas. Configure uma instância do banco de dados para transações coordenadas e configure a outra instância para transações não coordenadas.
Utilize as instruções ESQL COMMIT e ROLLBACK para confirmar e recuperar transações auxiliares do banco de dados. Obtenha operações fora da transação principal, especificando a palavra-chave UNCOORDINATED nas instruções individuais do banco de dados (por exemplo, as instruções INSERT e UPDATE).
Nem todos os sistemas de enfileiramento têm a capacidade do banco de dados descrita acima. No caso do WebSphere MQ, cada operação de leitura ou gravação individual não coordenada em uma fila tem uma ação de confirmação implícita, portanto, você não pode colocar duas mensagens e depois decidir confirmar ambas ou recuperar ambas. As instruções COMMIT e ROLLBACK, portanto, operam somente nos bancos de dados.
A descrição acima menciona fluxos de mensagens, mas não menciona nós. A maneira como um fluxo de mensagens é dividido em nós não tem nenhum efeito nas transações. Para operações em bancos de dados, um número qualquer de nós pode fazer atualizações na transação principal e para um número qualquer de transações auxiliares sem restrição.
Quando todas as atualizações de banco de dados são realizadas em transações auxiliares, configure o atributo Transação Coordenada do fluxo de mensagens para não para afetar todas as referências de tabela fora da transação principal. Isso significa que não é necessário especificar o atributo em cada operação de banco de dados.