ローカルとサーバのデータを同期する

 WebStorageを始めとするHTML5関連技術により生じた最大の変化は、オフライン(クライアントサイド)処理の強化である。これは言い換えれば、「Webサービスを実現するための補完言語としてのJavascript」という位置付けから、「Javascriptで書かれたローカルアプリケーションとシームレスに繋がるWebサービス」という位置づけへの転換である。この概念の変化は、いくつかの大きな問題を生む。その1つは、オフラインで動作しているローカルアプリケーションのデータと、サーバサイドのデータベースの同期の問題である。

 同期の問題に関連して、特に多人数で一つのデータにアクセスするようなシステムにおいてユーザアクションのコンフリクトという悩ましい問題を生み出す。もちろん、従来型のシステムでも同様にコンフリクトの問題はあったが、従来型のシステムでは、ユーザがサーバからデータを取得して編集し再びサーバに保存するまでの時間(以下、「アクセス時間」と呼ぶ)は短時間であった。それに対し、ローカルで独立したシステムの場合は「アクセス時間」が非常に長くなり、コンフリクトする可能性が高くなる。従来型のシステムでは、コンフリクトを防ぐためにファイルを排他ロックし、1人の編集者が他の編集者の書き込みアクセスをブロックやり方がしばし用いられてきたが、「アクセス時間」が長いシステムにおいては排他ロックするやり方は他のユーザに制限を与え不便な場合が多い。

 このような「アクセス時間」の長いシステムにおいてサーバ側とローカル側のデータの同期を解決するシステムとして典型的なものに構成管理ツールがある。構成管理ツールでは、ローカルの編集差分やサーバの更新差分をやり取りして、編集箇所のコンフリクトがあれば、適宜対応するやり方をとるが、ローカルで独立して動作する大規模アプリケーションを実装する際には、このようなアプローチが必須になると考える。

 TeaOSで取っているアプローチは、全ての書き込み可能なディレクトリ、ファイル、もしくはクラスターに対して、ダーティーフラグを立てるやり方である。下記例にあるように、属性’d’に対して、1が新規作成フラグ、2が更新フラグ、3が削除フラグである。

var createdFile={'d':1,'t':'lf','C':"This's data."};
var modifiedFile={'d':2,'t':'lf','C':"This's data."};
var removedFile={'d':3,'t':'lf','C':"This's data."};

 実際には、ユーザはダーティフラグを意識せずとも下記のようなAPIを実行することでフラグが設定される。

var file=new File('/home/teaos/1.txt','w');
...
file.close();

ちなみに、ローカルの変更をサーバに反映させるにはFSys.commit(path,options), サーバの変更をローカルに反映させるにはFSys.update(path,options)を呼び出す。更新先のサービスによって処理が異なってくるが、その差異はドライバ層で吸収する構造になっている。

なお、TeaOSでは、ファイルやディレクトリにメタ情報を付加することができるが、このメタ情報についても差分管理をしている。差分情報を細かく管理すればより柔軟な設計が可能になる。

カテゴリー: html5_storage   タグ: , , ,   この投稿のパーマリンク

コメントを残す