如何让 Mobilink 同步表以便最新更新的表不会被覆盖?
这是场景。 我有一个 Oracle 统一数据库。 我正在使用 Mobilink 将 Oracle 与手持设备上使用的 SqlAnywere 数据库同步。 如果用户 A 将其手持设备上的远程数据库中的一条记录更改为“首先更新”,然后 10 分钟后,用户 B 将其手持设备上的同一记录更新为“第二次更新”,我希望统一数据库始终显示“第二次更新”两个设备已同步。 目前,如果用户B 在用户A 之前同步,统一数据库将显示“先更新”。
Here is the scenario. I have an Oracle consolidated database. I am using Mobilink to synchronize Oracle with a SqlAnywere database that is being used on a handheld.
If userA changes a record in the remote DB on their handheld device to "updated first" and then 10 minutes later userB updates the same record on their handheld device to "updated second" I want the consolidated database to always show "updated second" after the two devices are synchronized. Currently if userB synchronizes before userA the consolidated database will read "updated first".
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
现在,您在 MobiLink 服务器中使用默认冲突解决方案,因此默认情况下最后一次同步获胜。 您需要实施自己的冲突解决方案来处理此问题。
这需要在远程数据库上完成两件事:
1) 远程数据库的表中需要有一列与统一数据库同步,以跟踪记录在远程站点更新的时间。
2) 您必须信任远程站点的系统时钟。 如果人们弄清楚如何解决冲突,并且希望确保他们的数据赢得冲突,则没有什么可以阻止用户将远程设备上的系统时间更改为下周,更新他们的数据,将系统时间更改回来以及然后同步。
在整合时,您需要实施冲突解决方案,这并不难。 只要您的表不包含任何 blob,您就可以在表的 upload_update 事件中写入冲突解决方案。 让我们假设远程数据库中的一个表如下所示:
我们还假设合并中的一个表看起来非常相似,但还有另一个最后修改的列来跟踪行在合并中发生更改的时间。
通常,您的 upload_update 事件将如下所示:
相反,我们将重写您的 upload_update 事件以调用存储过程,并传入远程数据库中的旧行值。
存储过程的关键是我们将进行更新,但更新的 where 子句将包括主键值和远程数据库中的旧行值。 如果有人更改了合并处的行,则此更新将更新零行,并且我们知道发生了冲突。 如果它更新一行,则不存在冲突。 您的存储过程将如下所示(下面是伪 SQL):
有关冲突解决的详细信息,请参见 v10 文档的以下部分:
MobiLink - 服务器管理
同步技术
处理冲突
http://dcx.sybase.com/index .php#http%3A%2F%2Fdcx.sybase.com%2Fhtml%2Fdbmlen10%2Fml-conflicts-synch.html
Right now, you are using default conflict resolution in the MobiLink Server, so by default the last synch in wins. You'll need to implement your own conflict resolution scheme to handle this.
This will require two things to happen at the remote database :
1) There will need to be a column in the table at the remote database that synchronizes to the consolidated database that tracks the time that records were updated at the remote site.
2) You will have to trust the system clock at the remote sites. Should people figure out how conflicts are being resolved and they want to make sure their data wins the conflict, there is nothing stopping a user from changing the system time on their remote device to next week, updating their data, changing the system time back and then synchronizing.
At the consolidated, you'll need to implement conflict resolution, which isn’t that hard. As long as your table does not include any blobs, you can write your conflict resolution in the upload_update event for the table. Let’s assume a table at the remote database that looks like :
Let’s also assume a table at the consolidated that looks very similar, but also has another last modified column to track when rows have changed at the consolidated.
Typically, your upload_update event would look something like this :
Instead, we’ll re-write your upload_update event to call a stored procedure and also pass in the old row values from the remote database.
The key to your stored procedure is that we are going to do an update, but the where clause of the update will include both the primary key values AND the old row values from the remote database. If someone has changed the row at the consoliated, this update will update zero rows, and we know a conflict occurs. If it updates a row, then there was no conflict. Your stored procedure will look something like this ( pseudo-SQL below ) :
For more information on conflict resolution, see the following section of the v10 docs :
MobiLink - Server Administration
Synchronization Techniques
Handling conflicts
http://dcx.sybase.com/index.php#http%3A%2F%2Fdcx.sybase.com%2Fhtml%2Fdbmlen10%2Fml-conflicts-synch.html
假设您已实现基于时间戳的下载或快照下载,如果自上次同步以来另一个远程更新了整合,则远程将更新以匹配整合。
顺便说一句,如果您设置同步模型 (http://dcx.sybase.com/index.php#http%3A%2F%2Fdcx.sybase.com%2Fhtml %2Fdbmgen10%2Fmg-mg-about-s-5060632a.html),适用于版本 10 及更高版本。 在“创建同步模型”向导中,或者在创建模型后的“映射”页面中,您可以选择是否需要基于行或基于列的冲突检测以及不同类型的冲突解决。 您想要的对应于“时间戳”冲突解决选项,您可以在其中选择现有的时间戳列。
仅供参考,该向导比“映射”页面更多地解释了这些选项,因此我建议首先在向导中探索这些选项。 请注意,如果“较新的获胜,使用您维护的时间戳列”选项呈灰色,则意味着同步表中没有时间戳列。
创建模型后,您可以在“事件”页面中预览生成的脚本。 完成模型设置后,您可以部署它来创建 SQL 和批处理文件和/或将 SQL 直接应用到数据库。
Assuming you have implemented timestamp-based downloads or snapshot downloads, then the remote will be updated to match the consolidated, if the consolidated was updated by another remote since the last synchronization.
BTW, the type of conflict resolution you want is available if you set up a synchronization model (http://dcx.sybase.com/index.php#http%3A%2F%2Fdcx.sybase.com%2Fhtml%2Fdbmgen10%2Fmg-mg-about-s-5060632a.html), available in version 10 and above. Either in the Create Synchronization Model wizard, or in the Mappings page after the model is created, you can choose whether you want row-based or column-based conflict detection, and different types of conflict resolution. What you want corresponds to the "timestamp" conflict resolution option, where you pick an existing timestamp column.
FYI, the wizard explains the options more than the Mappings page, so I recommend exploring those options in the wizard first. Note that if the "Newer wins, using a timestamp column that you maintain" option is grayed, it means that there is no timestamp column in the synchronized table(s).
Once you've created a model, you can preview the generated scripts in the Events page. When you have finished setting up the model, you deploy it to create SQL and batch files and/or apply SQL directly to the databases.