Once you have determined why and what you are replicating and to which sites, you want to look at when the data needs to be delivered to each site and how to keep the data synchronized between all the distributed sites. This will help you determine your propagation schedule and method. We have already explained what Propagation means in Chapter 1, All the Pieces: The Parts of an Oracle 11g Streams Environment. Now, let's dig a bit deeper and look at how Propagation and data synchronization interrelate.

Data Propagation is one aspect of data synchronization; conflict detection and resolution are the other two aspects.

The two methods of data Propagation are Synchronous and Asynchronous.

Synchronous propagation is a distributed transaction in its truest form. All sites have to "agree" to commit the change before it can be committed anywhere; including the originating site. This means that all sites take out a lock on the piece of data until the transaction is committed at all sites. While the distributed transaction has a lock on the data, no other processes can modify that data. Thus, synchronous propagation, enforces the dynamic ownership model, and ensures immediate data synchronization.

Due to the "all or nothing" commit of synchronous propagation, it is not recommended for use between any two sites that have intermittent or unstable connectivity. If any site involved in the transaction is not reachable, the transaction cannot be committed anywhere, even at the origination site. This can have a significant negative impact on work flow and business productivity. Synchronous propagation should only be used for business data requiring immediate transactional consistency (for instance, banking, tickets/reservations, financial, and so on). In these cases, network connectivity, and stability must be of paramount design focus.

With this said, remember that Streams replication is, by nature, asynchronous.

Asynchronous propagation allows autonomy between the replicated sites, but still supports eventual data synchronization via the autonomous distribution of a copy of the transaction to each site. Asynchronous propagation also allows data divergence. Asynchronous propagation allows a change to be committed at the originating site without "agreement to commit" from the other sites where the change will be sent. This means that over some amount of time, the data between the sites will temporarily diverge. If a user changes the same piece of data at a target site before the previous change is received, it will cause a permanent divergence of data that will require conflict resolution when the initial change is received and applied at the site.

This means that special attention needs to be paid to when you schedule your asynchronous propagation between sites to avoid permanent data divergence. If your change flow is unidirectional, your propagation schedules may be more relaxed in Single-Site ownership models. However, if your change flow is bidirectional , you will want to reduce Propagation lag as much as possible.

To help determine when and how you will distribute data changes throughout your distributed system, take into account the following: