Impostare la proprietà Transazione
per i seguenti nodi, se compaiono in questo flusso di messaggi:
- Compute
- Database
- DataDelete
- DataInsert
- DataUpdate
- Filter
- Mapping
- Warehouse
E' possibile impostare la proprietà Transazione
sui seguenti valori:
- Automatico
- Su qualsiasi aggiornamento, eliminazione e aggiunta effettuata dal nodo viene eseguito il commit o il
rollback una volta completata l'elaborazione del flusso di messaggi. Se il flusso di messaggi si completa con esito
positivo, si esegue il commit di tutte le modifiche. Se il flusso di messaggi non si completa con esito positivo, si esegue il
rollback di tutte le modifiche.
Se si desidera che tutta l'elaborazione del flusso di messaggi sia coordinata, è
necessario selezionare questo valore.
- Commit
- L'azione intrapresa dipende dal sistema su cui è stato distribuito il flusso di
messaggi:
Se si desidera unire i nodi con un tipo di transazione
Automatico e
Commit nello stesso flusso di messaggi, in cui i nodi operano sullo stesso
database esterno, è necessario utilizzare connessioni ODBC separate: una per i nodi che non devono eseguire il
commit fino al completamento del flusso di messaggi e una per i nodi che devono eseguire
il commit immediatamente. In caso contrario, i nodi che eseguono il commit immediatamente
eseguiranno il commit di tutte le operazioni portate avanti dai precedenti nodi in
Automatico.
Nota: su piattaforme diverse da z/OS, i singoli database relazionali
potrebbero supportare questa modalità di operazione o meno.
Se si definisce più di una connessione
ODBC si potrebbero verificare problemi di blocco del database.
In particolare, se un nodo con un tipo di transazione Automatico
esegue un'operazione, come INSERT o UPDATE, che causa il blocco di un oggetto database
(come una tabella) e il nodo successivo prova ad accedere a quell'oggetto database utilizzando una
connessione ODBC differente, si verifica un blocco a tempo indefinito (blocco critico).
Il secondo nodo è in attesa che il blocco acquisito dal primo nodo venga
rilasciato, ma il primo nodo non eseguirà il commit delle operazioni e non rilascerà
il blocco fino a quando il flusso di messaggi non verrà completato; questo non accadrà mai perché
il secondo nodo è in attesa che venga rilasciato il blocco di database del primo nodo.
Tale situazione non può essere
individuata dalle routine automatiche DBMS di evitamento del blocco critico poiché le due
operazioni interferiscono tra loro indirettamente, utilizzando il broker.
Esistono due modi per evitare questo tipo di problema di blocco:
- Progettare il flusso di messaggi in modo che le operazioni senza commit (automatiche) non blocchino gli
oggetti di database a cui devono accedere operazioni successive che utilizzano una connessione ODBC
diversa.
- Configurare il parametro timeout blocco database in modo che un tentativo di acquisire un blocco abbia
esito negativo dopo un periodo di tempo specificato. Se un'operazione di database ha esito negativo a causa di un
timeout del blocco, viene generata un'eccezione che il broker gestisce nel modo usuale.
Per informazioni riguardo gli oggetti di database bloccati da particolari
operazioni e come configurare il parametro timeout del blocco database, consultare la documentazione
relativa al proprio prodotto database.
Impostare la proprietà Modalità transazione
per i seguenti nodi, se compaiono in questo flusso di messaggi: - MQInput
- MQOutput
- MQReply
- SCADAInput
- Nodo JMSInput
- Nodo JMSOutput
La tabella riportata di seguito fornisce un riepilogo delle azioni intraprese in risposta a
impostazioni specifiche delle proprietà per i nodi di input e di output.
Permanenza del messaggio a |
Modalità transazione del nodo di input |
Modalità transazione del nodo MQOutput o MQReply |
Il flusso di messaggi è coordinato a livello globale? |
Sì |
Sì |
Automatico |
Sì |
No |
Sì |
Automatico |
Sì |
Sì |
No |
Automatico |
No |
No |
No |
Automatico |
No |
Sì |
Automatico |
Automatico |
Sì |
No |
Automatico |
Automatico |
No |
Qualsiasi b |
Qualsiasi b |
Sì |
Sì |
Qualsiasi b |
Qualsiasi b |
No |
No |
Note: - La permanenza è importante solo per i messaggi ricevuti attraverso i protocolli WebSphere MQ Enterprise Transport, WebSphere
MQ Mobile Transport e WebSphere MQ Telemetry Transport.
- L'impostazione delle proprietà del nodo MQOutput o MQReply sovrascrive il valore impostato
qui.
- Le impostazioni della Modalità transazione dei nodi JMSInput e JMSOutput
sono diverse rispetto alla precedente tabella. Consultare Nodo JMSInput e Nodo JMSOutput per informazioni.
Il valore predefinito su ogni nodo di input è Sì,
il che significa che i messaggi in entrata sono elaborati nel punto di sincronizzazione. Inoltre, i messaggi inviati al nodo di output
sono consegnati nel punto di sincronizzazione. E' possibile modificare questo tipo di funzionamento se il nodo di output è
un nodo MQOutput o MQReply, entrambi con la proprietà Modalità transazione.
Se si imposta
la Modalità transazione in un nodo di input
su Automatico,
i messaggi in entrata sono elaborati nel punto di sincronizzazione solo se vengono
definiti come permanenti. I messaggi inviati al nodo MQOutput sono consegnati nel punto di sincronizzazione a meno che
non si modifichi esplicitamente la Modalità transazione nel nodo MQOutput.