Prioridade de Confirmação de Recursos Transacionais
É possível especificar a ordem de processamento dos recursos transacionais durante o processamento de two-phase commit.
- A otimização de one-phase commit ocorrerá com maior frequência.
- Os prováveis problemas causados pelo isolamento da transação serão resolvidos.
Para controlar a ordem de processamento dos recursos transacionais durante o processamento de two-phase commit, especifique a prioridade de confirmação de um recurso configurando o atributo de prioridade de confirmação em uma referência de recurso. Quanto maior a prioridade de confirmação, mais cedo o recurso é processado. Por exemplo, se um recurso tiver uma prioridade de confirmação de 10, ele será processado antes de um recurso com uma prioridade de confirmação de 1. O valor da prioridade de confirmação tem o tipo int e varia entre -2147483648 e 2147483647.
Se você não especificar um valor de prioridade de confirmação, um valor padrão igual a zero será designado ao recurso e utilizado ao ordenar os recursos no tempo de execução. Se dois ou mais recursos forem configurados com a mesma prioridade, incluído a prioridade padrão, eles serão processados em uma ordem não especificada ao serem referidos.
Você pode especificar o atributo de prioridade de confirmação em uma referência de recurso utilizando as ferramentas do Rational Application Developer. Para obter informações detalhadas, consulte o centro de informações do Rational Application Developer. O componente de aplicativo deve ter um descritor de implementação; você não pode especificar esse atributo se foi utilizada anotação.
Otimização de One-phase Commit
Em uma transação com two-phase commit, se cada recurso, exceto o último registrado na transação, optar pela leitura, indicando que esses recursos não estão interessados no resultado da transação, poderá ocorrer uma one-phase commit. Isso significa que o serviço de transação não precisa armazenar informações de recursos e transações que seriam necessárias para recuperar um two-phase commit, melhorando assim o desempenho.
É possível controlar a ordem de processamento dos recursos transacionais durante uma two-phase commit, portanto, você pode processar os recursos que provavelmente optarão pela leitura, primeiro. Desse modo, você aumenta as chances de ocorrência de uma one-phase commit.
![[z/OS]](../images/ngzos.gif)
Isolamento de Transação
Quando os recursos estão envolvidos em uma transação global, as atualizações feitas como parte de uma transação não são visíveis fora da transação até sua confirmação, isto é, esses recursos ficam isolados. Esse isolamento pode causar problemas com outros componentes do aplicativo que agem nas atualizações após sua confirmação. Por exemplo, o processamento adicional pode falhar ou pode falhar intermitentemente, porque as atualizações dependem da ordem e do tempo. Esse problema não ocorre com o trabalho do sistema de mensagens de barramento de integração de serviços no WebSphere Application Server, mas pode ser problema para outros provedores de sistemas de mensagens, por exemplo, o WebSphere MQ.
Se você especificar a ordem de confirmação dos recursos transacionais, os problemas causados pelo isolamento serão resolvidos em todos os sistemas transacionais, não apenas nos provedores de sistemas de mensagens e no barramento de integração de serviços, especificamente.
O exemplo a seguir descreve os problemas que podem ocorrer quando não é possível especificar a ordem de confirmação dos recursos transacionais. Um aplicativo atualiza uma linha em uma tabela de banco de dados e, em seguida, envia uma mensagem JMS que aciona o processamento adicional da linha. Essas duas ações são executadas na mesma transação global, portanto, ficam isoladas até a confirmação de seus respectivos recursos. Se a atualização na linha for confirmada antes do envio da mensagem, o processamento acionado pela mensagem poderá acessar a linha atualizada e processá-la. Se a ação de envio da mensagem for confirmada primeiro, ela poderá acionar o processamento adicional da linha antes de o banco de dados ter confirmado a atualização da linha. Nesta situação, a linha atualizada continuará isolada e não visível e o processamento adicional da linha falhará.
Este problema pode ser mais complicado porque depende da ordem e do tempo. Se o banco de dados for confirmado primeiro, o problema não ocorrerá. Se a ação de envio da mensagem for confirmada primeiro, o problema poderá ocorrer, mas dependerá de o trabalho do banco de dados ser confirmado antes de a mensagem acionar o processamento adicional da linha. Portanto, o problema pode ser intermitente, dificultando a identificação de sua causa.
Restrições com Versões Anteriores do WebSphere Application Server
Se você especificar a prioridade de confirmação de um recurso, isto é, especificar valores diferentes do padrão de 0, a prioridade de confirmação será incluída no log do parceiro em uma seção de unidade recuperável. Esta seção no arquivo de log é reconhecida no WebSphere Application Server Versão 7.0 ou mais recente, mas não em versões anteriores do servidor de aplicativos.
Portanto, se um aplicativo usar o atributo de prioridade de consolidação, não é possível instalar este aplicativo em um cluster com versões combinadas no qual um ou mais servidores no cluster estão em versões do WebSphere Application Server anteriores à versão 7.0.
Também, se um aplicativo que usa o atributo de prioridade de consolidação estiver instalador em um cluster, não é possível incluir posteriormente um servidor a esse cluster se o servidor estiver em uma versão do WebSphere Application Server que seja anterior à Versão 7.0.
Para obter informações gerais sobre as diferentes versões do produto, consulte o tópico "Visão Geral de Migração, Coexistência e Interoperabilidade".