Discussion :

[pifor]

Le coordinateur d'une transaction distribuée ne sait pas ce que si passe sur les bases concernées par la transaction distribuée. Oracle a choisi de démarrer une transaction locale par défaut pour que le coordinateur ne se pose pas de question à la fin de la transaction distribuée: le coordinateur envoie COMMIT ou ROLLBACK à chaque transaction locale.

[Michel SALAIS]

je pense qu'il met à jour le catalogue local pour stocker le SCN distant

One consequence of the SCN gap is that two consecutive SELECT statements can retrieve different data even though no DML has been executed between the two statements. For example, you can issue an update statement and then commit the update on the remote database. When you issue a SELECT statement on a view based on this remote table, the view does not show the update to the row. The next time that you issue the SELECT statement, the update is present.

Ceci ne me semble pas convaincant. Dans la mesure ou un select dans une base observe le SCN à son départ, je ne vois pas comment ça peut arriver à cause de l'écart de SCN entre les deux bases
A moins que l'hypothèse sous-jacente à ce propos est l'utilisation du SCN de la base locale et non celui de la base concernée.

Maintenant la synchronisation des SCNs est indispensable pour les transcations distribuées

[Michel SALAIS]

Sujet évoqué là.

Et voici ce qui dit Tom Kyte:

Je parle de mémoire:
Il se peut que ce soit une autre base qui sera désignée comme coordinateur globale lorsque la validation est entammée (two phases commit) et donc ce coordinateur n'a aucune idée de ce qui a été fait par l'initiateur de la transaction distribuée. Un paramètre d'initialisation commit_point_strength permet d'élire l'une des bases en fonction de sa valeur.

C'est peut être ce point qui est à l'origine de toute la question