The Guaranteed Message Delivery System ensures that:
All replicated operations are applied in the correct order. See Ensuring that operations are applied in the correct order.
No replicated operations are missed. See Resending lost or corrupt messages.
No replicated operation is applied twice. See Ensuring that messages are applied only once.
The Guaranteed Message Delivery System uses the following information:
The status information maintained in the SYSREMOTEUSER system table This table contains a row for each subscriber, with status information for messages sent to and received by that subscriber. For example:
On the consolidated database, the SYSREMOTEUSER system table contains a row for each remote user.
On each remote database, the SYSREMOTEUSER system table contains a single row with information about the consolidated database.
The SYSREMOTEUSER system table is maintained by the Message Agent (dbremote).
On the subscriber database, the Message Agent (dbremote) sends a confirmation to the publisher database to ensure that the SYSREMOTEUSER system table is maintained correctly at each end of the subscription.
The information in the header of the messages The Message Agent (dbremote) reads the header information in the messages and uses this information to update the SYSREMOTEUSER system table. A message includes the following information in its header:
Its resend_count A counter that keeps track of the number of times the receiving database has lost messages.
In the following example, the resend_count is 1.
Current message's header: (1-0000942712-0001119170-0) |
The transaction log offset of the last COMMIT in the previous message In the following example, the transaction log offset of the last commit in the previous message is 0000942712.
Previous message's header:(0-0000923357-0000942712-0) Current message's header: (0-0000942712-0001119170-0) |
The transaction log offset of the last COMMIT in the current message In the following example, the last commit in the current message is 0001119170:
Current message's header: (0-0000942712-0001119170-0) |
If a transaction spans several messages, both transaction log offsets can be identical until the final message contains a COMMIT.
In the following example, the COMMIT does not occur until the fourth message:
(0-0000942712-0000942712-0) (0-0000942712-0000942712-1) (0-0000942712-0000942712-2) (0-0000942712-0001119170-3) |
A sequence number When a transaction spans several messages, this sequence number is used to order the messages correctly.
A sequence number of zero can indicate that:
The message is not part of a multi-part message if the transaction log offsets are different.
In the following example, the messages are not part of a multi-part message:
(0-0000923200-0000923357-0)
(0-0000923357-0000942712-0)
|
The message is the first of a multi-part message if the transaction log offsets are the same.
In the following example, the first message is part of a multi-part message:
(0-0000942712-0000942712-0) (0-0000942712-0000942712-1) (0-0000942712-0000942712-2) (0-0000942712-0001119170-3) |
Ensuring that operations are applied in the correct order
Resending lost or corrupt messages
Ensuring that messages are applied only once
| Discuss this page in DocCommentXchange. Send feedback about this page using email. |
Copyright © 2009, iAnywhere Solutions, Inc. - SQL Anywhere 11.0.1 |