ArcGIS Server Banner

Disconnected synchronization (ArcInfo and ArcEditor only)

Disconnected synchronization (ArcInfo and ArcEditor only)

Release 9.3 E-mail This TopicPrintable VersionGive Us feedback
Note: This topic was updated for 9.3.1.

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 then 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 or USPS.

At any time, a replica can be either a data sender or a data receiver. To learn how to determine if a replica is a data sender or a data receiver, see Managing replicas. 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 acknowledgement 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 then receiving an acknowledgment message from the child. Here, the parent is the data sender and the child is the data receiver.

sync_disconnected1

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.

sync_disconnected2

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.

NOTE: To see how to synchronize in a disconnected environment, see Synchronizing disconnected replicas.

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 re-sent. 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 reexport 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.

sync_disconnected4

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.

sync_disconnected3

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 Synchronizing disconnected replicas to find out how to send a data changes message with only instructions to switch roles.

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 changes sent previously 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 (see Synchronizing disconnected replicas to find out how). These can be imported by the data receiver as long as it was correctly reported that changes sent previously have been received. If the system detects that changes sent previously 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 replica log to detect if errors have occurred during synchronization. The log also provides 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.

See Also

  • About synchronization
  • Synchronizing connected replicas
  • Synchronizing disconnected replicas
  • Synchronizing with filters and related data
  • Synchronizing topology
  • Synchronizing geometric networks
  • Synchronizing connected replicas
  • Synchronizing disconnected replicas
  • Applying schema changes