O modelo transacional descreve a maneira na qual é possível usar transações nos fluxos de mensagens para executar determinadas tarefas e resultados.
Um fluxo de mensagens consiste nas seguintes partes constituintes:
As etapas a seguir representam uma sequência típica de eventos na transação do fluxo de mensagens:
Durante esta sequência de eventos, o estado dos dados no sistema muda, independentemente do número de recursos externos que o fluxo de mensagens acessa e se ele gera uma mensagem de saída.
-----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 é obtida da origem de entrada. Nos tempos 2, 3, 4 e 5, os dados são usados para atualizar recursos externos; por exemplo, uma tabela de banco de dados ou uma fila de saída. 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 estes eventos, o estado dos dados não altera; este estado é indicado no diagrama pelo símbolo =.
Se ocorrer uma falha no sistema (por exemplo, uma perda de energia no computador no qual o broker está em execução), as mudanças no estado dos recursos externos que foram feitas antes da falha foram implementadas, mas nenhuma alteração adicional ocorre 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.
Para evitar o problema que foi descrito anteriormente, o broker e os gerenciadores de recursos externos com os quais ele trabalha, possuem um modelo transacional. O broker inicia uma transação quando os dados são recebidos por um nó de entrada no fluxo de mensagens e conclui quando o processamento nesses dados é concluído. Para obter mais detalhes sobre transações do fluxo de mensagens, consulte Transações de Fluxos de Mensagens.
-----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, os dados de entrada chegam da origem de entrada; por exemplo, uma fila. Antes do tempo 1, não existe nenhum dado extra no sistema; este estado é indicado no diagrama pelo símbolo -. Após o tempo 1, o estado representa o fato de que os dados foram recebidos da origem de entrada, para que possam ser restaurados, se necessário. Nos tempos 2, 3, 4 e 5, os dados são usados para atualizar recursos externos como bancos de dados ou arquivos. Novamente, o estado dos dados extras muda para que as alterações nesses recursos externos possam ser desfeitas, se necessário. No tempo 6, as mensagens de saída são enviadas, o sistema está inativo e dados extras no sistema não existem mais.
Entre estes eventos, o estado dos dados extras não é alterado; este estado é indicado pelo símbolo =. Se uma falha ocorrer entre o tempo 1 e o tempo 6, dados extras serão usados para restaurar o estado original dos dados mantidos pelos recursos externos. Portanto, efetivamente, nenhum dado de saída foi gravado no destino de saída, nenhum dos recursos externos foi atualizado e os dados de entrada não foram recebidos da origem de entrada. Se nenhuma falha ocorrer, as alterações se tornarão permanentes no tempo 6 (e a operação desfazer que segue uma falha subsequente não irá desfazer as alterações).
Esse modo de operação é conhecido como modo de transação coordenada. 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 se ou quando a falha aparece, todas as mudanças nos recursos externos associadas a uma mensagem de entrada são feitas ou nenhuma das mudanças é feita. No entanto, esse comportamento nem sempre é adequado, conforme ilustrado pelos exemplos a seguir:
Se seus fluxos de mensagens tiverem requisitos como estes, será possível configurar fluxos de mensagens para alterar um ou mais recursos em uma transação separada ou auxiliar. Nem todos os gerenciadores de recursos suportam este tipo de transação.
Para alguns recursos, uma transação auxiliar é iniciada automaticamente; por exemplo, cada conexão com o banco de dados inicia uma transação que é específica para aquele banco de dados e todas as atualizações feitas nessa transação podem ser confirmadas ou retrocedidas.
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 que são registrados para restaurar o estado original, se necessário. A linha 1st AUX representa uma transação auxiliar. No tempo 3, um recurso externo é atualizado e outra atualização é feita no tempo 6. No tempo 7, o fluxo de mensagens determina que todas as alterações que devem ser feitas na transação auxiliar estão concluídas e ela confirma as alterações.
Se o fluxo de mensagens falhar antes do tempo 7, o estado do sistema ficará inalterado porque ambas as transações serão retrocedidas. Se a falha ocorrer após o tempo 7 mas antes do tempo 9, a transação auxiliar já terá sido confirmada. Entretanto, a transação principal será retrocedida. Se não ocorrer uma falhar até o tempo 9, ambas transações são confirmadas.
É possível usar mais de uma transação auxiliar e fazer várias atualizações nas tabelas de banco de dados que podem ser confirmadas ou retrocedidas. É possível, então, fazer alterações adicionais nas mesmas tabelas de banco de dados, ou em tabelas diferentes e, em seguida, confirmar ou retroceder essas alterações.
Cada banco de dados que você usa possui sua própria transação auxiliar; portanto, se o fluxo de mensagens atualizar tabelas que pertencem a diferentes instâncias de banco de dados (diferentes nomes de origem de dados), uma transação auxiliar existirá para cada banco de dados. É possível, opcionalmente, confirmar ou retroceder estas transações auxiliares individualmente. Atualizações que não foram confirmadas ou retrocedidas quando o fluxo de mensagens foi concluído (no tempo 9 no exemplo mostrado anteriormente) são confirmadas ou retrocedidas automaticamente pelo broker, de acordo com o êxito ou a falha do processamento.
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 possuem o recurso de banco de dados que está descrito na seção anterior. Com o WebSphere MQ, cada operação de leitura ou gravação individual não coordenada em uma fila possui uma ação de confirmação implícita. Portanto, não é possível colocar duas mensagens e, em seguida, decidir confirmar ambas ou retroceder ambas. As instruções COMMIT e ROLLBACK, portanto, operam somente nos bancos de dados.
As seções anteriores se referem a fluxos de mensagens, mas não a nós. A maneira na qual um fluxo de mensagens é dividido em nós não tem efeito nas transações. Para operações nos bancos de dados, um número ilimitado de nós pode fazer atualizações na transação principal e em um número ilimitado de transações auxiliares, sem restrição.