1.1.1

1. Reads messages from the queue.
2. Creates a batch of the messages.
3. Synchronously distributes the batch to the remote site and waits for a reply.
4. Removes the batch from the queue after the remote site has successfully replied.
Because the batch is not removed from the queue until after the remote site has replied, the message cannot get
lost. However, this also means that a message can be processed more than once in certain failure scenarios. If a
site goes offline in the middle of processing a batch of messages, that same batch is sent again after the site is
back online. See About High Availability for WAN Deployments on page 233.
The batch is configurable via the batch size and batch time interval settings, which you can specify when you
create a gateway sender (see CREATE GATEWAYSENDER on page 484). A batch of messages is processed
by the queue when either the batch size or the time interval is reached. In an active network, it is likely that the
batch size will be reached before the time interval. In an idle network, the time interval will most likely be
reached before the batch size. This may result in some network latency that corresponds to the time interval.
How a Gateway Handles Batch Processing Failure
These types of exceptions can occur during batch processing:
• A gateway receiver fails with acknowledgment. If processing fails while the receiving gateway is processing
a batch, it replies with a failure acknowledgment containing the exception, including the identity of the message
that failed, and the ID of the last message successfully processed. The sending gateway removes the successfully
processed messages and the failed message from the queue and logs the exception and the failed message
information. The sender then continues processing the messages remaining in the queue.
• The receiving gateway fails without acknowledgment. If the receiving gateway does not acknowledge a sent
batch, the sender does not know which messages were successfully processed, so it re-sends the entire batch.
• No remote gateways are available. If a batch processing exception occurs because no remote gateways are
available, the batch remains on the queue. The sending gateway waits for a time, then attempts to re-send the
batch. The time periods between attempts is five seconds. The existing server monitor continuously attempts
to connect to the remote gateway, so eventually a connection is made and queue processing continues. Messages
build up in the queue and possibly overflow to disk in the meantime.
Supported and Unsupported Topologies
Make sure you use a supported multi-site topology and understand why invalid topologies can lead to data
inconsistency.
• Supported Topologies on page 219
• Unsupported Topologies on page 220
See also Limitations of Multi-Site Replication on page 234.
Supported Topologies
SQLFire supports WAN topologies that use gateways to connect each individual distributed system to each other
distributed system in the WAN. This parallel network topology is a robust configuration in which any one of
the sites can go down without disrupting communication between the remaining sites. This configuration also
guarantees that no site receives multiple copies of the same DML operation.
The parallel topology for three sites is shown in the following figure. In this scenario, a DML operation originating
in any site is distributed to the remaining two sites, and neither site forwards the event further. If any site is
removed, the other two maintain a parallel topology.
219
SQLFire Deployment Models