...
All the above processes can be on the same server, or on different servers. The Fetcher process is an optional process and is not shown in above diagram.
Multiple Mine, Apply and Fetcher processes are possible for the same replication, enabling simple to complex replication topologies.
Optimistic commit
Dbvisit Replicate (both MINE and APPLY) does not wait for the commit to start replicating. This ensures there is minimal lag in large transactions and there is no need to hold inflight transactions in queues or memory.
This is similar to how Oracle implements optimistic commit. Oracle also does not wait for the commit to be issued before writing the data to the database files.
When there is a rollback, then Dbvisit Replicate has to do more work in order to undo the transactions that have been applied, and this is similar to how Oracle works.
Dbvisit Replicate adheres to autonomous transactions. Transactions that are not committed are not visible to other transactions until they have been committed. So if a large transaction has been replicated, the data is there on the target database but it will not be visible to the outside world until the transaction has been committed on the source database.