Questo esempio dimostra che solo un nodo MQInput alla volta può estrarre i messaggi da una coda condivisa quando lo stesso token di serializzazione viene utilizzato da flussi di messaggi in esecuzione in gruppi di esecuzione separati sullo stesso broker.
Un flusso di messaggi identico MyFlowA viene distribuito a due gruppi di esecuzione chiamati MYGroupA e MYGroupB sul broker MQ01BRK.
In questo caso, non è richiesto che il gestore code partecipi ad un gruppo di condivisione della coda. La coda di input INQueue è definita come local con disposizione QMGR.
BIP2656I MQ01BRK MyGroupB 11 UNABLE TO OPEN QUEUE 'INQueue' SUL GESTORE CODE WEBSPHERE BUSINESS INTEGRATION 'MQ01': PERCHE' IL TOKEN DI SERIALIZZAZIONE MyToken123ABC è in uso. NON E' RICHIESTA ALCUNA AZIONE DELL'UTENTE
Il flusso di messaggi MyFlowA nel gruppo di esecuzione MyGroupB non è in grado di elaborare l'input perché il token di serializzazione passato è già utilizzato all'interno del gestore code (dal nodo MQInput nel flusso di messaggi MyFlowA nel gruppo di esecuzione MyGroupA). Ciò è indicato dal codice motivo 2271 (MQRC_CONN_TAG_IN_USE) nel messaggio bip2623.
Se il primo gruppo di esecuzione è annullato dall'operatore, termina in modo anomalo o viene eliminato durante una nuova distribuzione della configurazione del broker, il nodo di input nel secondo gruppo di esecuzione è in grado di ricevere i messaggi di input dalla coda INQueue.
BIP2091I MQ01BRK MyGroupB 11 IL BROKER SI E' RICONNESSO A WEBSPHERE BUSINESS INTEGRATION CORRETTAMENTE : ImbCommonInputNode(785)
Il flusso di messaggi MyFlowA nel gruppo di esecuzione MyGroupB è in grado di ripristinare l'elaborazione dei messaggi dalla coda condivisa INQueue.QSG.
Notare che, sebbene la serializzazione dell'input possa essere ottenuta in un modo simile configurando la coda di input per l'input esclusivo, ciò non assicura l'integrità dei messaggi durante una situazione di recupero. Ciò può essere ottenuto solo utilizzando il token di serializzazione come descritto in questo esempio.