2

これがシナリオです。Oracle 統合データベースがあります。Mobilink を使用して、ハンドヘルドで使用されている SqlAnywere データベースと Oracle を同期しています。userA がハンドヘルド デバイスのリモート DB のレコードを「updated first」に変更し、10 分後に userB がハンドヘルド デバイスの同じレコードを「updated second」に更新した場合、統合データベースは常に「updated second」と表示されるようにします。 2 つのデバイスが同期されます。現在、userB が userA の前に同期する場合、統合データベースは「最初に更新」と読み取ります。

4

2 に答える 2

4

現在、Mobile Link サーバーでデフォルトの競合解決を使用しているため、デフォルトでは最後の同期が優先されます。これを処理するには、独自の競合解決スキームを実装する必要があります。

これには、リモート データベースで次の 2 つの処理が必要です。

1) リモート・サイトでレコードが更新された時間を追跡する統合データベースと同期する、リモート・データベースの表に列が必要です。

2) リモート サイトのシステム クロックを信頼する必要があります。競合がどのように解決されているかを理解し、データが競合に勝つことを確認したい場合、ユーザーがリモート デバイスのシステム時刻を来週に変更し、データを更新し、システム時刻を元に戻し、次に同期。

統合では、競合の解決を実装する必要がありますが、これはそれほど難しくありません。テーブルに BLOB が含まれていない限り、テーブルの upload_update イベントに競合の解決を書き込むことができます。次のようなリモート データベースのテーブルを想定してみましょう。

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
);

また、統合されたテーブルが非常によく似ていると仮定しますが、統合されたテーブルで行がいつ変更されたかを追跡するために、最後に変更された列がもう 1 つあります。

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
);

通常、upload_update イベントは次のようになります。

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}'
);

代わりに、upload_update イベントを書き直して、ストアド プロシージャを呼び出し、リモート データベースから古い行の値を渡します。

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}’
);

ストアド プロシージャの鍵は、更新を行うことですが、更新の where 句には、主キーの値とリモート データベースからの古い行の値の両方が含まれます。誰かが統合された行を変更した場合、この更新はゼロ行を更新し、競合が発生することがわかります。行を更新する場合、競合はありませんでした。ストアド プロシージャは次のようになります (以下の擬似 SQL )。

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;

競合解決の詳細については、v10 ドキュメントの次のセクションを参照してください。

Mobile Link - サーバー管理

同期テクニック

競合の処理

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

于 2009-06-03T14:24:00.307 に答える
2

タイムスタンプ ベースのダウンロードまたはスナップショットのダウンロードを実装していると仮定すると、前回の同期以降に統合が別のリモートによって更新された場合、リモートは統合と一致するように更新されます。

ところで、同期モデル ( http://dcx.sybase.com/index.php#http%3A%2F%2Fdcx.sybase.com%2Fhtml%2Fdbmgen10%2Fmg ) を設定すれば、必要な種類の競合解決を利用できます。-mg-about-s-5060632a.html )、バージョン 10 以降で利用可能。[同期モデルの作成] ウィザード、またはモデル作成後の [マッピング] ページで、行ベースまたは列ベースのどちらの競合検出が必要か、およびさまざまな種類の競合解決を選択できます。必要なものは、既存のタイムスタンプ列を選択する「タイムスタンプ」競合解決オプションに対応しています。

参考までに、ウィザードは [マッピング] ページよりも多くのオプションを説明しているため、最初にウィザードでこれらのオプションを調べることをお勧めします。「あなたが維持しているタイムスタンプ列を使用して、新しい方が勝つ」オプションがグレー表示されている場合は、同期されたテーブルにタイムスタンプ列がないことを意味することに注意してください。

モデルを作成したら、生成されたスクリプトを [イベント] ページでプレビューできます。モデルのセットアップが完了したら、モデルをデプロイして SQL およびバッチ ファイルを作成したり、SQL をデータベースに直接適用したりします。

于 2009-06-04T14:10:09.960 に答える