Wie bringt man Mobilink dazu, Tabellen zu synchronisieren, damit die zuletzt aktualisierte Tabelle nicht überschrieben wird?

Question

Hier ist das Szenario. Ich habe eine konsolidierte Oracle-Datenbank. Ich verwende Mobilink, um Oracle mit einer SqlAnywere-Datenbank zu synchronisieren, die auf einem Handheld verwendet wird. Wenn BenutzerA einen Datensatz in der Remote-DB auf ihrem Handheld-Gerät auf "zuerst aktualisiert" ändert und dann 10 Minuten später den gleichen Datensatz auf ihrem Handheld-Gerät auf "Aktualisiert Sekunde" aktualisiert, möchte ich, dass die konsolidierte Datenbank immer "aktualisierte Sekunde" anzeigt nachdem die zwei Geräte synchronisiert sind. Wenn BenutzerB vor BenutzerA synchronisiert wird, liest die konsolidierte Datenbank aktuell "zuerst aktualisiert".

Answer 1

Momentan verwenden Sie die Standardkonfliktauflösung im MobiLink-Server, sodass standardmäßig die letzte Synchronisation in gewinnt. Sie müssen dafür Ihr eigenes Konfliktlösungsschema implementieren.

Das wird zwei Dinge benötigen in der entfernten Datenbank geschehen:

1) Es muss eine Spalte in der Tabelle in der entfernten Datenbank sein, die in der konsolidierten Datenbank synchronisiert, die die Zeit verfolgt, dass die Datensätze aktualisiert wurden an der entfernten Stelle.

2) Sie müssen die Systemuhr an den Remote-Standorten vertrauen. Wenn Leute herausfinden, wie Konflikte gelöst werden und sie sicherstellen wollen, dass ihre Daten den Konflikt gewinnen, gibt es nichts, was einen Benutzer davon abhält, die Systemzeit auf seinem entfernten Gerät auf nächste Woche zu ändern, seine Daten zu aktualisieren, die Systemzeit zurück zu ändern dann synchronisieren.

Bei der konsolidierten müssen Sie die Konfliktlösung implementieren, die nicht so schwer ist. Solange Ihre Tabelle keine Blobs enthält, können Sie Ihre Konfliktlösung im upload_update-Ereignis für die Tabelle schreiben. Lassen Sie uns einen Tisch in der entfernten Datenbank übernehmen, die wie folgt aussieht:

create table Admin (
    admin_id   bigint default global autoincrement(1000000) primary key, 
    data    varchar(64) not null, 
    rem_last_modified timestamp not null default timestamp 
); 

Lassen Sie uns auch eine Tabelle in der konsolidierten übernehmen, die sehr ähnlich sieht, hat aber auch eine andere letzte Änderung Spalte zu verfolgen, wenn Zeilen in der konsolidierten geändert haben.

create table Admin (
    admin_id   bigint default global autoincrement(1000000) primary key, 
    data    varchar(64) not null , 
    rem_last_modified timestamp not null default ‘1900-01-01’, 
    cons_last_modified timestamp default timestamp 
); 

Normalerweise Ihr upload_update Ereignis wie folgt aussehen würde:

call ml_add_table_script('v1', 'Admin', 'upload_update', 
'update Admin set data = {ml r.data}, 
       rem_last_modified = {ml r.rem_last_modified} 
where admin_id = {ml r.admin_id}' 
); 

Stattdessen werden wir neu schreiben Ihre upload_update Ereignis eine gespeicherte Prozedur aufzurufen, und auch in den alten Zeilenwerte gehen von die entfernte Datenbank.

call ml_add_table_script('v1', 'Admin', 'upload_update', 
'call admin_upload_update({ml r.admin_id}, 
    {ml r.data}, {ml r.rem_last_modified}, 
    {ml o.data}, {ml o.rem_last_modified}’ 
); 

Der Schlüssel zu Ihrer gespeicherten Prozedur ist, dass wir ein Update tun, aber die where-Klausel des Updates wird sowohl die Primärschlüsselwerte und die alten Zeilenwerte aus der entfernten Datenbank werden. Wenn jemand die Zeile bei der Konsolidierung geändert hat, aktualisiert dieses Update null Zeilen und wir wissen, dass ein Konflikt auftritt. Wenn es eine Zeile aktualisiert, gab es keinen Konflikt.Ihre gespeicherte Prozedur wird so etwas wie dieser (pseudo-SQL unten) aussehen:

create procedure admin_upload_update ( 
    @admin_id bigint, 
    @new_data varchar(64), 
    @new_rem_lmod timestamp, 
    @old_data varchar(64), 
    @old_rem_lmod timestamp 
) 
begin 
    declare @cur_rem_lmod timestamp; 
    update admin set data = @new_data, rem_last_modified = @new_rem_lmod 
    where admin_id = @admin_id 
     and data = @old_data 
     and rem_last_modified = @old_rem_lmod; 
    if @@rowcount = 0 then 
     // conflict !! 
     select rem_last_modified into @cur_rem_lmod 
      from admin where admin_id = @admin_id; 
     if @new_rem_lmod > @cur_rem_lmod then 
      // update using new_data and new_rem_lmod 
     else 
      // do nothing, current values in cons wins 
     end if; 
    end if; 
end; 

Weitere Informationen zur Konfliktlösung finden Sie im folgenden Abschnitt der v10 docs:

Mobilink - Serveradministration

Synchronisationsmethoden

Konfliktbehandlung

http://dcx.sybase.com/index.php#http%3A%2F%2Fdcx.sybase.com%2Fhtml%2Fdbmlen10%2Fml-conflicts-synch.html

Answer 2

Angenommen, Sie haben zeitstempelbasierte Downloads oder Snapshots-Downloads implementiert, wird das Remote aktualisiert, damit es mit dem konsolidierten übereinstimmt, wenn das konsolidierte Netzwerk seit der letzten Synchronisierung von einem anderen Remote aktualisiert wurde.

Übrigens ist die gewünschte Konfliktlösung verfügbar, wenn Sie ein Synchronisationsmodell (http://dcx.sybase.com/index.php#http%3A%2F%2Fdcx.sybase.com%2Fhtml%2Fdbmgen10%2Fmg-mg-about-s-5060632a.html) einrichten, das in Version 10 und höher verfügbar ist. Entweder im Assistenten zum Erstellen eines Synchronisationsmodells oder auf der Seite "Zuordnungen", nachdem das Modell erstellt wurde, können Sie auswählen, ob Sie eine zeilenbasierte oder spaltenbasierte Konflikterkennung und verschiedene Arten der Konfliktlösung verwenden möchten. Was Sie wollen, entspricht der Option "timestamp conflict resolution", bei der Sie eine vorhandene timestamp-Spalte auswählen.

Zu Ihrer Information, der Assistent erklärt die Optionen mehr als die Seite Zuordnungen, daher empfehle ich, diese Optionen zuerst im Assistenten zu untersuchen. Beachten Sie, dass wenn die Option "Neuerer gewinnt, indem Sie eine Zeitstempelspalte verwendet, die Sie verwalten" grau unterlegt ist, dass in den synchronisierten Tabellen keine Zeitstempelspalte vorhanden ist.

Sobald Sie ein Modell erstellt haben, können Sie eine Vorschau der generierten Skripts auf der Seite Ereignisse anzeigen. Wenn Sie das Modell eingerichtet haben, stellen Sie es bereit, um SQL- und Batch-Dateien zu erstellen und/oder wenden Sie SQL direkt auf die Datenbanken an.