Disconnected synchronization

This topic applies to ArcEditor and ArcInfo only.

Disconnected synchronization is performed in a disconnected environment.

For replicas in a disconnected environment, synchronization requires the user to manually perform the message exchange. This is achieved by exporting a message from one replica to a file and importing the message from the file on the relative replica. In disconnected systems, files can be transported on media such as CDs or DVDs and sent via a distribution agent such as private couriers, USPS, and so on.

At any time, a replica can be either a data sender or a data receiver. To learn how to determine whether a replica is a data sender or a data receiver, see A quick tour of replica management. A data sender exports data change messages to delta files that contain changes to be applied to the relative replica. A data receiver exports acknowledgment messages to acknowledgment files to confirm what it has received.

It is important for the data receiver to export acknowledgment messages as often as possible. If no acknowledgment messages are received, the data sender resends changes and maintains the information needed to resend changes until those changes are acknowledged. As a result, the data sender's geodatabase can become large, and new data change messages can also become large.

An ideal, although not required, practice is for the data receiver to send an acknowledgment message after receiving each data change message. It is also important to note that one acknowledgment message acknowledges all data change messages. For example, if a replica receives three data change messages and imports each, it can send a single acknowledgment message to acknowledge all three.

The following shows the parent replica sending changes to the child replica and receiving an acknowledgment message from the child. Here, the parent is the data sender, and the child is the data receiver.

The data sender and data receiver can also switch roles. The switch is initiated by the data sender when it sends a final data change message that includes instructions to switch roles. Once the message has been imported by the data receiver, the roles are switched, and the system is ready to send data in the opposite direction.

The diagram below shows the parent replica sending a data change message with instructions to switch roles. When the parent replica exports the message, it becomes the data receiver. When the child receives the message, it becomes the data sender. The child replica then sends a data change message to the parent.

The replica type determines the message exchange. Two-way replicas use data change and acknowledgment messages and can switch roles. With one-way replicas, the parent is always the data sender and can't switch roles, but it is still important for the child to send acknowledgment messages. For checkout replicas, the child is always the data sender, and no acknowledgment messages are needed.

The above describes a basic message exchange pattern where messages are sent back and forth between the parent replica and the child replica. If you continue with this pattern, the system will function properly and even correct itself if messages are lost. However, you may also want to consider the following specific message exchange scenarios.

Resending unacknowledged messages

The system also allows replicas to resend unacknowledged data changes. You may want do this when, as a data sender, you either know or suspect that an earlier data change message has been lost and needs to be resent. Another option is to wait until the next time you send data changes, since by default, this includes both new changes and any unacknowledged changes.

The diagram below shows a case where you need to resend unacknowledged data changes. Here, the parent sends a data change message and switches from sender to receiver. The message, however, gets lost leaving both the parent and the child as data receivers. To solve this issue, the option to re-export unacknowledged messages is available to the data receiver that has just switched roles. In this case, it allows the parent to resend the message to switch roles to the child.

Acknowledging changes after switching roles

After switching roles, the option to export an acknowledgment message is available for the data sender to acknowledge the message that switched the roles. Another option is to send a data change message, since it will implicitly acknowledge this message. If you don't plan on sending a data change message in the near future, however, you may want to send an acknowledgment message.

In the diagram below, the parent sends a data change message that switches roles. When the child receives the message, it becomes a data sender, but since it has just switched, the system still allows it to send an acknowledgment message.

Switching roles without sending data changes

It is possible to send a data change message with instructions to switch roles but without any data changes. You may want to do this if, as the data sender, you need to get changes from the data receiver but are not ready to send data changes. See Exporting a data change messagefor more information on sending a message to switch roles without sending any data.

Verbal acknowledgment

When sending data changes, all new data changes and unacknowledged data changes are sent by default. New changes are any inserts, updates, and deletes applied to the replica version since the last data change message was exported. Unacknowledged data changes include previously exported changes for which you have not received an acknowledgment. If you have sent several data change messages for which you have not received an acknowledgment, the messages can become large.

The best solution is for the data receiver to send an acknowledgment message. However, depending on the communication system, this can be difficult.

An alternative is to use verbal acknowledgment. In this situation, the sender gets a verbal acknowledgment from the person managing the data receiver that previously sent changes have been received. You can use the replica manager to determine what changes have been sent and received by a replica. The data sender then sends only new changes. These can be imported by the data receiver as long as it was correctly reported that previously sent changes have been received. If the system detects that previously sent changes have not been imported, it will result in an error. If several data change messages are sent at once, they must be imported in the correct order. The system will result in an error if you attempt to import in an incorrect order.

When errors occur, error messages are provided. However, if using an automated system, you may not be present to see the errors. In this case, you can use the replca activity log to detect whether errors have occurred during synchronization. The log also provide instructions on how to recover when appropriate.

It is important to note that although the messages will be smaller, the verbal acknowledgment approach is not equivalent to using acknowledgment messages. Importing acknowledgment messages is the only way for the system to drop system versions required to resend changes for a replica. These system versions can hinder compression over time and make the sender's geodatabase large. For this reason, it is still important to periodically use acknowledgment messages even when using the verbal acknowledgment approach.