In the following sequence diagram the workflow of several operations to be replicated is shown:
The red lines on the left hand side are the synchronous thread of the caller. These occur inside the database as PL-SQL invocations. The blue lines on the right hand side represent symbolically the publishing thread and the update (or distribution) thread.
On initial update, information about tables to be watched was gathered. Depending on the configuration a trigger was added to the table to be replicated.
When a change occurs on a table to be replicated, the trigger on that table is fired. On Insert, update or delete the trigger ensures that the change is serialized as an xml literal to be stored either in the content or in the oldcontent column of the ITEMS or in both. The entry is then stored in the ITEMS table. Such an approach allows to gather replication data even if the XmlBlaster should be down for some reason. This means that if the xmlBlaster is not available this only delays the replication until the xmlBlaster is available again, but no data will be lost. Now the replication data is temporary queued in this table until it is picked up by the DbWatcher.
As we saw in the previous section, the replication data has been queued in the ITEMS table. It is now the job of the DbWatcher polling thread to detect that something new is available on that table, pick it up, process it, publish it and finally remove the processed data from the queue.
The format of the replication message is conform to the standard format for the DbWatcher. It is specified its XSD Schema. For each transaction one single message is sent. If the transaction is constituted by several writing actions, then the message will contain multiple change actions.
The prepared messages are published by the DbWatcher to the xmlBlaster. All messages are handled persistently, so if a DbWatcher is running standalone and the XmlBlaster is currently unavailable, such messages are queued in a persistent storage. When the XmlBlaster becomes available again queued messages are published. Even for cases where the DbWatcher is running embedded the messages are persistent. This to avoid loss of messages on runlevel changes. When messages are published, i.e. are stored in the persistent queues of all interested slaves, the DbWatcher thread returns and removes the processed messages from the ENTRIES table. On an XmlBlaster crash happening after having successfully published the messages but before removing the entries from the table it could occur that the same change entry is published twice. This is detected later by the DbWatcher and the message is marked to avoid double delivery.
When the DbWatcher is publishing the messages it is not necessary for the real slave to be available since the data is stored persistently on a serverside queue (also called the callback queue). If it is available, or when it becomes available, the message is delivered to the slave if and only if the message is not obsolete. A message can be obsolete if it was already delivered, i.e. if it was marked by the DbWatcher as a double. Messages are also obsolete if they are older of an ongoing initial update. In other cases the message is delivered.
On the slave side, the responsible class taking care of the storage is the DbWriter. The DbWriter is a general purpose class used to store messages on a database. It is a minor plugin framework which makes use of interfaces which can be implemented differently for specific purposes. One of such specific purposes is indeed replication. Therefore the class making the job is the ReplicationWriter.
The ReplicationWriter checks what kind of action it is, performs the necessary filtering and modifications and executes the change on the replica database as a jdbc call. There is the possibility to ignore certain actions, the data content can be modified or the name of the destination tables or the columns can be modified. All this can be configured, and where configuration does not suffice the user can implement its own business-specific code for the available interfaces.
When an exception occurs a check is made to determine what the problem is. On INSERT or CREATE, if an entry was already found, the action is ignored and a warning is written to the logs. If an entry to be updated or deleted is not found, a warning is also issued. Other errors are logged and the exception is thrown back to the server. The server, on receiving the exception temporary stops the delivery to that specific slave client. At this point it is the responsibility of the administrator to analyze the error, fix it, and manually reactivate the delivery.