Defina a propriedade Transaction para os
seguintes nós, se aparecerem neste fluxo de mensagens:
- Compute
- Database
- DataDelete
- DataInsert
- DataUpdate
- Filter
- Mapping
- Warehouse
Você pode definir a propriedade
Transaction para os
seguintes valores:
- Automatic
- Todas as atualizações, exclusões e inclusões realizadas pelo nó
serão consolidadas ou revertidas quando o processamento do fluxo de
mensagens for concluído.
Se o fluxo de
mensagens for concluído com êxito, todas as alterações serão
consolidadas.
Se o fluxo de mensagens não for concluído com êxito, será feita a
reversão de todas as alterações.
Para que todo o processamento do fluxo de mensagens seja coordenado,
será necessário selecionar esse valor.
- Commit
- A ação tomada depende do sistema no qual o fluxo de mensagens foi
implementado:
Para misturar nós com transacionalidade
Automática e
Consolidada
no mesmo fluxo de mensagens em que os nós operam no mesmo banco de
dados externo, você deve utilizar conexões ODBC separadas: uma para
os nós que não deverão ser consolidados até a conclusão do fluxo de
mensagens e uma para os nós que deverão ser consolidados
imediatamente. Caso contrário, os nós consolidados imediatamente
também farão com que todas as operações realizadas pelos nós
Automáticos
anteriores também sejam consolidadas.
Nota: Nas plataformas diferentes do z/OS, bancos de dados relacionais individuais podem suportar ou não esse modo de operação.
Se você definir mais de uma conexão ODBC, poderão ocorrer
problemas de travamento no banco de dados. Em
especial, se um nó com transacionalidade Automatic
realizar uma operação, como INSERT ou UPDATE, que cause o travamento
de um objeto do banco de dados (como uma tabela), e um nó seguinte
tentar acessar esse objeto do banco de dados utilizando uma conexão
ODBC diferente, ocorrerá um travamento (congelamento) infinito.
O segundo nó aguarda pela
liberação do travamento do primeiro, mas o primeiro nó não
consolidará suas operações e liberará seu travamento até que seja
concluído o fluxo de mensagens; isso nunca ocorrerá porque o segundo
nó está aguardando pela liberação do travamento do banco de dados do
primeiro nó.
Essa situação não pode ser detectada por nenhuma
rotina de revogação de congelamento automático do DBMS, porque as duas
operações estão interferindo entre si indiretamente, utilizando o
intermediário.
Existem duas maneiras para evitar esse
tipo de problema de travamento:
- Projete o fluxo de mensagens para que as operações (automáticas)
não consolidadas não travem objetos do banco de dados, cujas
operações subseqüentes que utilizem uma conexão ODBC diferente,
precisam acessar.
- Configure o parâmetro de tempo limite da trava do banco de dados
para que uma tentativa de adquirir uma trava falhe após um período de
tempo específico. Se uma operação do banco de dados falhar em
decorrência de um tempo limite de bloqueio, será emitida uma exceção
que o intermediário manipulará de maneira normal.
Para obter informações relativas a quais objetos do banco de
dados serão travados por determinadas operações e como configurar o
parâmetro de tempo limite do banco de dados, consulte a documentação
do produto do banco de dados.
Defina a propriedade
Transaction Mode
para os seguintes nós, se aparecerem neste fluxo de mensagens: - MQInput
- MQOutput
- MQReply
- SCADAInput
- Nó JMSInput
- Nó JMSOutput
A tabela abaixo fornece um resumo das medidas tomadas em
resposta às definições de propriedades específicas para os nós de
entrada e de saída.
Persistência de Mensagem a |
Modo de Transação do Nó Input |
Modo de Transação do Nó MQOutput ou MQReply |
O fluxo de mensagens é globalmente coordenado? |
Sim |
Sim |
Automático |
Sim |
Não |
Sim |
Automático |
Sim |
Sim |
Não |
Automático |
Não |
Não |
Não |
Automático |
Não |
Sim |
Automático |
Automático |
Sim |
Não |
Automático |
Automático |
Não |
Qualquer b |
Qualquer b |
Sim |
Sim |
Qualquer b |
Qualquer b |
Não |
Não |
Notas: - A persistência é relevante apenas para mensagens recebidas através dos protocolos WebSphere MQ Enterprise Transport, WebSphere
MQ Mobile Transport
e WebSphere MQ Telemetry Transport.
- A definição da propriedade do nó MQOutput ou MQReply substitui o valor definido
aqui.
- As configurações do Modo de Transação dos nós JMSInput e JMSOutput são definidas de forma diferente da tabela acima. Consulte Nó JMSInput e Nó JMSOutput para obter informações.
O padrão em cada nó input é
Sim, o que
significa que as mensagens que chegam são processadas sob o ponto de
sincronização. Além disso, as mensagens enviadas para
o nó output são entregues sob o ponto de sincronização. Você poderá
alterar esse comportamento se o nó de saída for um nó MQOutput ou
MQReply e se os dois possuírem uma propriedade
Modo de Transação.
Se você definir o Modo de Transação em um nó input como para Automático, as mensagens de entrada
serão processadas sob o ponto de sincronização apenas se estiverem definidas como persistentes.
As mensagens enviadas para o nó MQOutput serão entregues sob o ponto
de sincronização, a menos que você altere explicitamente o
Modo de Transação no
nó MQOutput.