Transacionalidade JMS

Os destinos JMS que fornecem mensagens a um nó JMSInput ou recebem mensagens de um nó JMSOutput podem ser coordenados pelo ponto de sincronização como parte de uma transação global do fluxo de mensagens.

Transações Envolvendo o Coordenador do Ponto de Sincronização

Um diagrama que representa o fluxo de mensagens através de um nó JMSOutput, incluindo um Coordenador do Ponto de Sincronização.

Nesse diagrama, as mensagens são consumidas a partir de um tópico por um nó JMSInput e são produzidas para um nó JMSOutput da fila JMS. Os nós são conectados a, e estão na sessão com um provedor JMS. Qualquer nó input do fluxo de mensagens pode informar o Coordenador do Ponto de Sincronização externo quando uma transação do fluxo de mensagens é inicia e encerrada e se quaisquer recursos que foram utilizados pelo fluxo devem ser confirmados ou devem sofre rollback.

O Coordenador do Ponto de Sincronização envia pedidos compatíveis com XA/Open a todos os Gerenciadores de Recursos participantes para informá-los que devem ser preparados. Quaisquer alterações são, então, confirmadas ou sofrem rollback. Os Gerenciadores de Recursos, como o WebSphere MQ, o DB2 e qualquer provedor JMS compatível com XA, podem participar de uma transação global. O Coordenador do Ponto de Sincronização externo é o WebSphere MQ nas plataformas distribuídas e RRS (Resource Recovery Services) no z/OS.

Os nós JMSInput e JMSOutput podem participar de uma transação global apenas se o provedor JMS ao qual eles estão conectados suportar a interface XA/Open por meio da Classe JMS XAResource. Um provedor JMS de exemplo é o WebSphere MQ Java Client.

Transações Pendentes

As transações pendentes podem ocorrer quando um Gerenciador de Recursos não responde a uma chamada do Gerenciador do Ponto de Sincronização, sendo que a chamada é para confirmar ou efetuar rollback de recursos. Durante a inicialização do gerenciador de filas do WebSphere MQ do intermediário, uma etapa de recuperação inicial é realizada para assegurar que quaisquer transações pendentes sejam resolvidas antes que os fluxos de mensagens do intermediário comecem a processar nova entrada. Um provedor JMS que participa das transações globais do intermediário é incluído nessa etapa de recuperação.

Configuração para Ativar o Suporte à Transação Global

Configuração adicional é requerida para ativar o suporte à transação global para o nó JMSInput e JMSOutput. Você deve concluir as seguintes etapas:
  1. Configure a propriedade do Fluxo de Mensagens Transação Coordenada para sim.
  2. Para cada nó JMSInput ou JMSOutput requerido para participar da transação global, configure a propriedade Avançada Modo de Transação para global.
  3. Crie um connection factory de fila e forneça um nome padrão recoverXAQCF ou forneça um nome definido pelo usuário. Consulte o nó JMSInput ou JMSOutput para obter detalhes adicionais sobre como criar os objetos administrados JNDI.
  4. Nas plataformas distribuídas, uma tarefa de administração do WebSphere MQ é requerida antes da implementação. Essa tarefa é necessária para registrar um componente intermediário com o gerenciador de filas. O componente, que é referido como um arquivo do Comutador, é uma biblioteca compartilhada (um DLL no Windows).

    Quando o gerenciador de filas do WebSphere MQ do intermediário é inicializado, ele carrega o arquivo do Comutador. O arquivo do Comutador encaminha as chamadas de transação XA/Open do Coordenador do Ponto de Sincronização para o Provedor JMS. Isso assegura que os recursos JMS que participam da transação podem ser coordenados na sincronização com outros Gerenciadores de Recursos envolvidos na mesma transação.

    A tarefa varia por plataforma.
    • Linux e UNIX
      Para o gerenciador de filas do intermediário para cada provedor JMS que pode ser utilizado por um nó JMSInput, coloque uma entrada de sub-rotina em um arquivo de inicialização, por exemplo qm.ini. Segue um exemplo de uma entrada de sub-rotina que pode ser incluída quando você estiver utilizando o WebSphere MQ Java como o provedor JMS:
      XAResourceManager:
      	Name=WBIWMQJMS
          SwitchFile=/<Caminho da Instalação>/lib/JMSSwitch.so
          XAOpenString=<Depósito de Informações do Provedor de Contexto Inicial>,
                    <Local das Ligações JNDI>'
                    <Proprietário LDAP>,
                    <Credenciais LDAP>,
                    <Nome da Connection Factory de Recuperação>
          ThreadOfControl=THREAD
      Em que:

      <Caminho da Instalação> é o local da instalação do WebSphere Message Broker. Este valor é obrigatório.

      Os parâmetros fornecidos em XAOpenString são delimitados por vírgula e têm posição específica. Qualquer parâmetro opcional ausente deve ser representado por uma vírgula se outros parâmetros forem fornecidos posteriormente na cadeia.
      • <Depósito de Informações do Provedor de Contexto Inicial> Esse é o identificador Depósito de Informações do Provedor de Contexto Inicial para o provedor JMS. Este valor é obrigatório.
      • <Local das Ligações JNDI> Esse é o caminho de arquivo para o arquivo de ligação ou o local do diretório LDAP dos objetos administrados pelo JNDI que podem ser utilizados para criar um depósito de informações do provedor de contexto inicial para a conexão JMS. Ao fornecer o caminho de arquivo ao arquivo de ligações, não inclua o nome de arquivo. Consulte o nó JMSInput ou JMSOutput para obter detalhes adicionais sobre como criar os objetos administrados de JNDI. Este valor é obrigatório.
      • <Proprietário LDAP> Esse é um parâmetro opcional que é utilizado para especificar o proprietário (ID do usuário) que pode ser requerido quando um banco de dados LDAP for utilizado para reter os objetos administrados pelo JNDI.
      • <Credenciais LDAP> Esse é um parâmetro opcional que é utilizado para especificar as Credenciais (senha) que podem ser requeridas se um banco de dados LDAP protegido por senha for utilizado para reter os objetos administrados por JNDI.
      • <Nome do Connection Factory de Recuperação> Esse é um parâmetro opcional que é utilizado para especificar o nome de um objeto Connection Factory de Fila nos objetos administrados pelo JNDI para fins de recuperação, quando o nome não padrão for requerido.

      Você deve especificar uma sub-rotina no arquivo .ini do gerenciador de filas do intermediário para cada provedor JMS que você deseja utilizar, ou seja, deve haver uma sub-rotina para cada novo provedor JMS, sendo que o provedor JMS pode ser especificado por qualquer nó JMSInput ou JMSOutput incluído em um fluxo de mensagem que está em execução em um intermediário.

      Os valores para o depósito de informações do provedor de Contexto Inicial e Local de ligações JNDI na sub-rotina devem corresponder aos especificados nos nós JMSInput ou JMSOutput nos fluxos de mensagens.

      Os parâmetros LDAP devem corresponder aos especificados através do comando mqsicreatebroker ou mqsichangebroker.

      O nome do Depósito de Informações do Provedor de Recuperação deve corresponder ao nome de um Connection Factory de Fila criado nos objetos administrados por JNDI. Se isso for omitido, um depósito de informações do provedor padrão chamado recoverXAQCF é utilizado. Em qualquer um dos dois casos, esse valor deve referir-se a um objeto administrador por JNDI que já foi criado.

      Segue uma sub-rotina de exemplo:

      XAOpenString=com.sun.jndi.fscontext.RefFSContextFactory,
           /u/myJndiFileLocation,
           ,
           ,
           myRecoveryQCFName    
      Onde os parâmetros LDAP são omitidos, mas uma Connection Factory de Fila definida é especificada para recuperação.
    • Em plataformas Windows

      Como no Linux e Unix, as mesmas informações são requeridas no Windows, mas isso é configurado utilizando o snap-in WebSphere MQ Explorer ou WebSphere MQ Services, dependendo da versão do WebSphere MQ que você está utilizando. No Windows, o arquivo do Comutador é chamado de JMSSwitch.dll. Consulte o WebSphere MQ System Administration Guide para obter detalhes sobre como atualizar o arquivo qm.ini. A entrada extra, chamada de XACloseString, deve corresponder aos valores fornecidos para XAOpenString.

    • No z/OS

      No WebSphere Message Broker, o único provedor JMS atualmente suportado é o IBM WebSphere MQ Java Client. O único modo de transporte suportado no momento para o cliente é o modo BIND. Nenhuma outra etapa de configuração é requerida

    Para obter informações adicionais, consulte a seção Configurando para Transações Coordenadas nos tópicos Nó JMSInput e Nó JMSOutput.
  5. O provedor JMS pode fornecer arquivos jar adicionais requeridos para suporte transacional. Consulte a documentação do provedor JMS para obter informações adicionais. Por exemplo, nas plataformas distribuídas (não z/OS), o provedor JMS do WebSphere MQ fornece um arquivo jar extra, com.ibm,mqetclient.jar. Esse jar também deve ser incluído no diretório shared_classes do intermediário. No Windows, esse diretório é C:\Documents and Settings\All Users\Application Data\IBM\MQSI\shared-classes. Para obter informações adicionais, consulte a seção sobre como disponibilizar o cliente do provedor JMS para Nós JMS nos seguintes tópicos: Nó JMSInput.

Opção do Provedor JMS

Qualquer provedor JMS que esteja em conformidade com o Especificação Java Message Service, Versão 1.1 e que suporte a API JMS XAResource através da sessão JMS pode ser utilizado se a coordenação da transação for requerida.

Se o designer da mensagem tiver especificado um provedor não compatível com XA, somente o modo não transacional é suportado. Nesse caso, você deve configurar a propriedade Modo de Transação para não para todos os nós JMSInput e JMSOutput.

Referências relacionadas
Tipos de Mensagem JMS
Estrutura da Mensagem JMS
Objetos Administrados por JNDI
Nó JMSInput
Nó JMSOutput
Avisos | Marcas Registradas | Downloads | Biblioteca | Suporte | Feedback
Direitos Autorais IBM Corporation 1999, 2006 Última Atualização: 1 Sep 2006
ac24879_