Coordinatore degli impegni e partecipanti multipli

I principi e i metodi per mantenere la coerenza tra più di due sistemi sono simili a quelli utilizzati per garantire la coerenza tra due sistemi. La differenza principale riguarda il ruolo di un sistema come coordinatore o partecipante quando un'unità di lavoro si estende su più sistemi.

Il coordinatore di un'unità di lavoro che coinvolge due o più DBMS deve garantire che tutti i sistemi rimangano coerenti. Dopo la prima fase del processo di commit a due fasi, il coordinatore dell' Db2 e attende che gli altri partecipanti indichino che possono confermare l'unità di lavoro. Se tutti i sistemi sono in grado di farlo, il coordinatore dell' Db2 e invia la decisione di conferma e ogni sistema conferma l'unità di lavoro.

Se anche un solo sistema indica che non può impegnarsi, il coordinatore dell' Db2 e comunica la decisione di annullare l'unità di lavoro a tutti i sistemi. Questo processo garantisce che i dati tra più DBMS rimangano coerenti. Quando il partecipante è un " Db2 ", segue la decisione del coordinatore, sia esso un altro " Db2 " o un altro DBMS.

Db2 è sempre il partecipante quando interagisce con i sistemi IMS, CICS® o WebSphere® Application Server . Db2 , tuttavia, può anche fungere da coordinatore per altri DBMS o per altri sottosistemi di Db2 e nella stessa unità di lavoro. Ad esempio, se un sistema di coordinamento ( Db2 ) riceve una richiesta che richiede anche la manipolazione dei dati su un altro sistema, il sistema di coordinamento ( Db2 ) propaga l'unità di lavoro all'altro sistema e funge da coordinatore per quel sistema.

Nella figura seguente, DB2A è il partecipante per una transazione di tipo " IMS ", ma Db2 diventa il coordinatore per i due server di database ( AS1 e AS2 ), per DB2B e per i rispettivi server di Db2 ( DB2C, DB2D e DB2E ).

Figura 1. Illustrazione di unità di lavoro multisito
Inizia la descrizione della figura. Questa figura è un diagramma che raffigura una rete di server di database. Fine descrizione figura.

Se la connessione tra l' DB2A e e il sistema di coordinamento dell' IMS e fallisce, la connessione diventa un filo conduttore. Tuttavia, i collegamenti di tipo " DB2A " con gli altri sistemi sono ancora in attesa e non sono considerati sicuri. Il recupero automatico avviene per risolvere il thread indubbio. Quando il thread viene recuperato, l'unità di lavoro si impegna o si annulla, e questa azione viene propagata agli altri sistemi coinvolti nell'unità di lavoro.