Guaranteed Message Delivery System

The Guaranteed Message Delivery System ensures that:

  • All replicated operations are applied in the correct order.

  • No replicated operations are missed.

  • No replicated operation is applied twice.

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 SQL Remote Message Agent (dbremote).

    On the subscriber database, the SQL Remote 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 SQL Remote 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)

 See also

Order of operations
Lost or corrupt messages
Messages are applied only once

Copyright © 2012, iAnywhere Solutions, Inc. - SQL Anywhere 12.0.1