WebSphere Message Broker, Versão 8.0.0.5 Sistemas operacionais: AIX, HP-Itanium, Linux, Solaris, Windows, z/OS

Consulte as informações sobre a versão mais recente do produto em IBM Integration Bus, Versão 9.0

Transações de Fluxos de Mensagens

Uma transação descreve um conjunto de atualizações que são feitas por um programa de aplicativo, que devem ser gerenciadas juntas. As atualizações podem ser feitas em um ou mais sistemas. As atualizações feitas pelo programa são controladas pelo ambiente no qual o programa é executado e todas são concluídas ou nenhuma é. Esta propriedade de uma transação é conhecida como consistência: as transações podem ter outras propriedades iguais a atomicidade, isolamento e durabilidade.

WebSphere Message Broker suporta transações e cada parte dos dados processados por um fluxo de mensagens possui uma transação associada. Uma transação de fluxo de mensagens é iniciada pelo broker quando dados de entrada são recebidos em um nó de entrada no fluxo; ela será confirmada quando o fluxo tiver concluído com essa mensagem ou retrocedida se um erro ocorrer.

Se o fluxo contiver mais de um nó de entrada, uma transação será iniciada para cada nó de entrada quando ele receber dados de entrada. Uma transação é iniciada para cada tipo de nó de entrada, incluindo nós de entrada definidos pelo usuário.

Os nós que você inclui em seu fluxo de mensagens fornecem processamento específico de uma mensagem, de acordo com a função definida de cada nó. O processamento que eles executam inclui trabalho interno, alguns dos quais é possível influenciar configurando as propriedades do nó. Alguns nós executam tarefas adicionais que podem afetar sistemas que são externos ao fluxo de mensagens ou ao broker.

Se um sistema externo, como um banco de dados, suporta o conceito de confirmação e retrocesso e pode fazer parte de uma transação do broker, é possível configurar o nó para que o trabalho que ele faz seja incluído na transação do fluxo. Dependendo do nó, também é possível especificar se o trabalho feito em um sistema externo que suporta transações é confirmado imediatamente ou quando a transação do fluxo de mensagens é concluída.

Muitos dos recursos com os quais seus fluxos de mensagens podem interagir são controlados por gerenciadores de recursos que podem participar de transações coordenadas; por exemplo, bancos de dados, mensagens e filas do WebSphere MQ e mensagens JMS. Outros gerenciadores de recursos não fornecem suporte transacional; por exemplo, o protocolo HTTP e sistemas de arquivos.

Confirmar ou Retroceder

Se o recurso puder participar de uma transação, será possível configurá-lo para que o trabalho que ele faz seja confirmado ou retrocedido apenas quando o fluxo de mensagens for concluído ou quando o nó for concluído. Os bancos de dados e as filas do WebSphere MQ são exemplos de recursos que podem ser usados desta maneira. Se o recurso não tiver comportamento transacional, todo o trabalho que ele faz será confirmado imediatamente. Por exemplo, arquivos e conexões HTTP não suportam transações.

As atualizações que são feitas por um fluxo de mensagens são confirmadas quando o fluxo processa a mensagem de entrada com êxito. As atualizações são retrocedidas se ambas as condições a seguir forem atendidas:

Em sistemas distribuídos, transações do fluxo de mensagens são gerenciadas pelo broker, por padrão. Estas transações são conhecidas como transações coordenadas pelo broker ou transações parcialmente coordenadas. Quando o controle retorna ao nó de entrada quando o fluxo conclui o processamento, o nó confirma ou retrocede as operações que foram executadas, excluindo os nós individuais que foram configurados para executar suas próprias confirmações e retrocessos ou que não possuem suporte para esta opção.

Se mais de um recurso for acessado pelo fluxo de mensagens, poderá ocorrer um erro que impedirá que todos os recursos confirmem todo o trabalho que foi feito. O broker levanta uma exceção e trata o processamento da exceção de uma maneira que é determinada pelo transporte que está envolvido. Por exemplo, mensagens que foram lidas a partir das filas WebSphere MQ são restauradas nessas filas e mensagens de falha são enviadas aos aplicativos que enviaram uma mensagem através de HTTP (porque HTTP não possui conceito de retrocesso). Devido a estas ações, o status dos recursos pode se tornar inconsistente.

Se for importante que seus dados e operações permaneçam consistentes e que todas as operações sejam confirmadas ou retrocedidas se uma ou mais operações falharem, é possível coordenar a atividade do fluxo de mensagens. A coordenação é fornecida por um gerenciador de transações externo que usa protocolos XA para interagir com gerenciadores de recursos. O gerenciador de transações é chamado pelo nó de entrada quando o fluxo de mensagens tiver concluído (com êxito ou com erros). O gerenciador de transações, em vez do nó de entrada e do broker, interage com os gerenciadores de recursos relevantes para iniciar as ações corretas para cada recurso. As transações que são controladas por um gerenciador de transações desta maneira são conhecidas como transações coordenadas globalmente.

No z/OS, as transações são sempre coordenadas globalmente; não é necessário escolher ou configurar esta opção.

Para obter uma descrição mais detalhada do modelo de transação no broker, consulte O modelo transacional.

A Função do Gerenciador de Transações

O resultado das ações executadas pelos fluxos de mensagens é o mesmo para transações coordenadas parcial e globalmente se o fluxo de mensagens for bem-sucedido em todas as suas ações. A vantagem de uma transação coordenada globalmente é a capacidade de assegurar que todas as ações ou nenhuma ação seja confirmada.

O gerenciador de transações externo, que opera uma estratégia two-phase commit, suporta casos em que um ou mais gerenciadores de recursos externos estão temporariamente indisponíveis durante o processo de cometimento. Esta janela potencialmente pequena para falha pode ser custosa para seu ambiente de negócios; o gerenciador de transações externo ajuda a eliminar a ocorrência de uma janela de falha. Portanto, a decisão de incluir um gerenciador de transações externo, que envolve uma sobrecarga do desempenho, é uma decisão administrativa, não uma a ser tomada no tempo de design do fluxo de mensagens.

Um gerenciador de transações externo não evita a perda de mensagem; mesmo se você usar a coordenação da transação, deverá configurar e codificar seus fluxos de mensagens para tratar possíveis erros o máximo que puder.

Para configurar um fluxo de mensagens para ser coordenado globalmente, também é necessário configurar seu ambiente para que seus gerenciadores de recursos sejam definidos no gerenciador de transações suportado:

Esta configuração pode precisar que você altere configurações no gerenciador de transações bem como nos gerenciadores de recursos participantes.

Modos e Bloqueios de Acesso ao Banco de Dados

É necessário usar conexões ODBC separadas se desejar incluir nós com status de transação Automático e nós com status de transação Confirmar no fluxo de mensagens, em que os nós operam no mesmo banco de dados externo. Configure uma conexão para os nós que não devem ser confirmados até a conclusão do fluxo de mensagens e uma segunda conexão para os nós que devem ser confirmados imediatamente.

Linux platformUNIX platformWindows platformEm sistemas diferentes do z/OS, os bancos de dados relacionais individuais podem não suportar este modo de operação.

Se você definir mais de uma conexão ODBC com a mesma origem de dados, poderá ter problemas de bloqueio do banco de dados. Em particular, se um nó com status de transação Automático executar uma operação, tal como uma INSERÇÃO ou uma ATUALIZAÇÃO, que faz com que um objeto de banco de dados (tal como uma tabela) seja bloqueado, e um nó subsequente tenta acessar esse objeto de banco de dados usando uma conexão ODBC diferente, ocorre um bloqueio infinito (conflito).

O segundo nó espera o bloqueio adquirido pelo primeiro ser liberado, mas o primeiro nó não consolida suas operações e libera seu bloqueio até que o fluxo de mensagens seja concluído. Entretanto, o fluxo não pode ser concluído, porque o segundo nó está esperando o bloqueio do banco de dados suspenso pelo primeiro nó ser liberado.

Uma situação desse tipo não pode ser detectada por uma rotina de evitação de conflito automática DBMS porque as duas operações estão interferindo uma na outra indiretamente usando o broker.

É possível usar uma das duas opções para evitar este tipo de problema de bloqueio:

Para obter informações sobre quais objetos do banco de dados estão bloqueados por operações particulares e como configurar o parâmetro de tempo limite de bloqueio de seu banco de dados, consulte a documentação do produto do banco de dados.

Exemplo de Transações nos Fluxos de Mensagens

A amostra a seguir demonstra o uso de transações coordenadas globalmente e as diferenças no fluxo de mensagens quando atualizações de banco de dados são coordenadas (o fluxo principal) e quando elas não são (o fluxo de erro).

Você só pode visualizar informações sobre amostras quando usa o centro de informações que está integrado ao WebSphere Message Broker Toolkit ou o centro de informações on-line. Você só poderá executar amostras quando usar o centro de informações que está integrado ao WebSphere Message Broker Toolkit.

Avisos | Marcas Registradas | Downloads | Biblioteca | Suporte | Feedback

Copyright IBM Corporation 1999, 2014Copyright IBM Corporation 1999, 2014.

        
        Última atualização:
        
        Última atualização: 2015-02-28 18:28:13


Tópico de ConceitoTópico de Conceito | Versão 8.0.0.5 | ac00645_