同步过程可以是单向的,也可以是双向的。本节讨论双向同步。双向同步过程分两个步骤:
图 2说明了在同步期间用户提交的更改将如何应用于源数据库。图表中的数字对应于其后的说明:
图 3说明在同步期间如何将源表中的更改应用于用户的移动设备上的 DB2 Everyplace 表。Sync Server 会将自用户的上一次同步以来所作的所有相关源数据更改发送至用户。Sync Server 只发送对其预订了用户的已更改数据。
图表中的数字对应于其后的说明。
同步可以由若干个同步会话组成。如果取消了同步过程,然后重新启动它,Sync Server 将尝试从未完成的第一个同步会话继续,而不是从头开始。
例如,假定您为一个预订请求对 100 个记录进行同步,并为另一个预订请求对 50 个记录进行同步。在您取消的时候,如果对 100 个记录进行的第一个预订已彻底同步,则重新启动同步时,将只对剩余的 50 个记录进行同步。这是因为只完成了第一个同步会话。
如果用户在同步会话期间取消同步,则不对该特定会话中的记录进行同步。如果用户成功地将设备上的所有已更改记录发送至服务器,但在服务器的答复期间取消了同步,则服务器将在用户重新连接至 Sync Server 时继续答复。
有时,客户机提交给 DB2 Everyplace Sync Server 的更改与其他客户机先前所作的更改或者同时对源表所作的更改之间会发生冲突。Sync Server 会跟踪复制预订中每个表中的每个记录的版本。会以类似方式跟踪每个客户机,以维持每个客户机与每个表上次同步时每个记录的版本。此信息允许 Sync Server 确定客户机是否试图根据某行数据的过时版本来更新该行。若客户机试图根据某行的数据的过时版本来更新该行,则更新会被拒绝。
当向中间层系统上的镜像表传送数据时,会应用冲突解决方案,如图 4所示。下一个复制周期会发生此情况。同步期间,在响应信息返回到客户机之前,将检测不到因客户机更新而产生的冲突。在下一次同步之前,对客户机更改的任何拒绝都不会反馈给客户机。若客户机的更改基于过时的记录,则该记录的正确版本将在原始同步请求中返回。
其更新被拒绝的客户机接收到被拒绝的记录和该记录的正确版本。被拒绝的记录将记录在客户机上的日志中。该记录的正确版本将替换客户机的 DB2 Everyplace 数据库中的原始(被拒绝)记录。
当 DataPropagator 将中间层中已更改的数据应用于源数据库时,可能会发生其他类型的冲突。有关如何管理及解决这些冲突的更多信息, 参见 DB2 Universal Database Replication Guide and Reference 和《DB2 通用数据库管理指南》。