外部端末の同期について

以下は、2010年1月現在開発中の機能についての説明です。

ここでは外部端末特有のデータ同期について説明します。

同期の必要性

スタンドアロン版では、一つのパソコンに一つのデータベースを格納しますので、 データ同期は必要ありません。

内部端末では、サーバ内の一つのデータベースを複数の端末から アクセスしますので、これもデータ同期は必要ありません。

外部端末の構成は上図のようになります。 サーバと同じLAN内にある「内部端末」ではネットワーク版と同様に複数端末がサーバ内データベースにアクセスしますが、 サーバにインターネット経由でアクセスする外部端末ではそれぞれ独自のデータベースを持ちます。

外部端末の持つデータは基本的には常にサーバ内データと同一でなければなりませんが、 この作業を「同期」と呼びます。

外部端末のデータ同期

外部端末データとサーバデータの同期は、以下のタイミングで自動的に行われます。

• 1.外部端末にてデータの変更が行われた場合、それをローカルデータベース（端末自身のデータベース）に 書き込むと同時にサーバにもアップロードする（図の青い線）。
• 2.サーバ内でデータの変更が起こった場合、それをダウンロードしてローカルデータベースに 書き込む（図の赤い線）。

1.の要因は、当然ながらその端末で操作を行った結果です。例えば、端末で顧客Aの 住所変更を行った場合、それはサーバデータベースにも反映されなければなりません。 このため、この変更はサーバに自動的に伝達されます。

2.の要因は、他の端末あるいはサーバ自身がサーバデータを変更した結果です。例えば、 他の端末で顧客Bの住所変更を行った場合、それは自動的にサーバデータに反映されますから、 その変更分をダウンロードしてローカルデータベースに反映します。

このように、外部端末データは常にサーバデータと同一でなければなりませんが、 ある瞬間を切り取ってみると、必ずしも同一では無いことがあります。 特に2.のダウンロードについては、数秒～数分のズレが発生することがあります。

アップロードとダウンロード

上述のように、外部端末でのデータ操作の結果はサーバにアップロードされる必要があり、 逆にサーバ内に格納された最新データは外部端末にダウンロードされる必要があります。 これについて詳しく見てみます。

いま、端末Aにて、Aさんの住所データを「東京都港区」から「米国カリフォルニア」に変更したとします。

アップロードはデータ操作が行われたときに発生します。 図のように、外部端末AにてAさんの住所を「米国カリフォルニア」に変更すると、 そのデータがサーバに転送されます。 この時点で、外部端末Bのデータはまだ旧住所（東京都港区）のままです。

外部端末は定期的・自動的にサーバの最新データをダウンロードします。 外部端末BはAさんの住所変更という最新データを検出しダウンロードすることにより、 ローカルデータベースの状態を最新にします。

このように、外部端末の持つデータは、ある瞬間を見てみると必ずしも最新ではありません。

この状況は、例えば巨大なウェブサイトにおいて、ユーザによる書き込みが必ずしもその瞬間に 反映されるわけではないことにも似ています。

しかしながら、最新のデータでなければ困ることもあります。 例えば、端末Bのデータがまだ旧住所データの状態であるのに、Aさんの電話番号を米国の電話番号に 変更しようとすると、住所は東京都のままであるのに電話だけ米国にするというおかしなことが起こってしまいます。

ロック

一般にマルチクライアントシステムでは「ロック」を行う必要があります。 これは、一人が（一つの端末）が、あるデータを変更するときには、他の人（他の端末）は そのデータを変更できないようにするものです。

• ロック無し
  複数の端末にて同時にAさんの住所を編集することができます。 しかし、編集結果が反映されるのは最後に書き込みを行ったデータのみで、それ以外は何のエラーも発生せずに失われます。 住所変更程度ならばそれほど問題にはなりませんが、複雑なデータの場合は深刻な問題が発生する場合があります。
• 楽観的ロック方式(Optimistic lock)
  この場合も複数の端末にて同時にAさんの住所を編集することができますが、 反映されるのは最初に書き込みを行った端末のみです。 それ以外の端末ではエラーが発生し、編集結果は失われます。 この方式は実現が簡単ですが、編集に多大な時間をかける場合や重要なデータを入力する場合にはリスクが大きすぎます。
• 悲観的ロック方式(Pessimistic lock)
  最初に編集を開始した端末しか編集操作を行うことができません。他の端末ではそのあいだ閲覧のみとなります。 編集は必ず完了し、編集結果が失われることはありません。

商品スタッフIIでは悲観的ロック方式を採用しています。

先の例で、外部端末AがAさんの住所を変更しようとする前には、あらかじめ自動的にそのデータをロックします。 これにより、他の端末はAさんの住所を編集することはできなくなります。

もちろんこれは、内部端末・外部端末に関わらずすべての端末に適用されます。 Aさんの住所を変更できるのは一つの端末に限定されます。

レコードバージョン

端末AがAさんのデータをロックし、住所を「東京都港区」から「米国カリフォルニア」に変更すると、 その変更がサーバ側に伝えられと同時にロックがはずれます。

その直後に端末BでAさんの住所を変更しようとすると、どうなるでしょうか？ まだサーバ内でのデータ変更が端末Bに伝えられていないとすると、端末Bでは古い「東京都港区」 という住所を変更することになってしまいます。

繰り返しですが、住所程度であれば問題はそれほど大きくありませんが、例えばこれが 「売掛顧客の入金済み金額」であったら大変なことになります。

つまり、編集操作（手入力による編集とは限りません）の際には、最新のレコードをロックする必要があります。 これを保証するために、本システムでは各レコードにレコードバージョンを保持しています。

先の例で、端末AがAさんのレコードをロックした際には、システム内の全データのレコードバージョンは１であったとします。

端末Aで編集を完了したとき、レコードバージョンは１増加します。 この時点で端末A及びサーバ内のレコードのバージョンは２となります。

この直後に端末BがAさんのレコードをロックしようとしても、サーバ内レコードとはバージョンが異なるので 許可されません。

サーバから端末Bにデータがダウンロードされ、端末B内のレコードが最新になってはじめて このレコードのロックをすることができます。

まとめ

• データを編集する際には、自動的にロックがかけられます。ロックが成功しないと編集はできません。
• データのロックができるのはただ一つの端末だけです。また、データが最新でない場合はロックできません。
• 端末にて変更されたデータはただちにサーバにアップロードされます。
• サーバ内でのデータ変更は定期的に端末にダウンロードされます。