GWT で作成された RIA Web クライアントでは、状態は Web クライアントで維持されますが、サーバーは (ほとんど) ステートレスです (これは、サイトのスケーラビリティを維持するために推奨される手法です)。
ただし、複数のユーザーがブラウザーで同じデータを表示しているときに、1 人のユーザーが何かを変更し、それがサーバーに送信されてデータベースに保存された場合、他のユーザーのブラウザーの状態は古いデータのままです。たとえば、ツリーが表示され、ユーザーの 1 人がツリーにアイテムを追加/削除します。
クライアントには多くの状態が存在する可能性があるため、クライアントの状態を同期させるための最良の手法は何ですか? これを処理するJavaフレームワークはありますか?
変更 (デルタ) のみをプッシュします。適用可能です。そうでない場合は、クライアントを完全に再同期します。これが、リモート クライアントに対して行うことです (GWT だけでなく、Eclipse RCP でも行います)。変更が小さくてローカルである間にデルタ コンテキストを送信し、グローバルな変更で再同期します。これには、洗練された差分プロトコルを設計する必要があり、多くの場合、リモート クライアント プロトコルをゼロから再設計する必要があります。
フレックスアプリケーションでも同じジレンマがあります。
これに対処する最善の方法は、サーバーとクライアントの間に数秒の間隔を保ち、各クライアントに状態を強制的にポーリングすることです。
私は次のアプローチを行いました。これは同期していない状況を解決するのではなく、発生する可能性のある状況を大幅に減らすだけであることに注意してください。
サーバー側には、各コレクション呼び出しのキャッシュが1つあります。クライアント側には、アプリケーションのインスタンスごとに、同じコレクションの1つのキャッシュがあります。
インスタンス1は、オブジェクトの配列をグリッドにロードします。（サーバーでコレクションの初期状態を構築します）
インスタンス2はロードして変更を加え、変更されたデータをサーバーに送信します。データベース情報は保持され、サーバーキャッシュが再構築されます。 （クライアントキャッシュは、サーバーコレクションを再度呼び出す必要がないローカルキャッシュも維持します。）
インスタンス1が同期していません。（次のポーリング間隔で同期されます） インスタンス2は、変更を担当するアプリであるため同期されます。
どちらのインスタンスも、変更の10秒間隔のように、サーバーを時々ポーリングします。 （サーバー側のキャッシュに変更があった場合は、次のインターバル呼び出しですべてのクライアントに新しい情報が提供されます。）
サーバー側レベルで変更がない場合、すでに登録されている1つのクライアントに情報は送信されません。 （これは、サーバーとクライアント間で情報が交換されないことを意味し、オーバーヘッドを削減します。）
3番目のクライアントが入ってくると、その状態は新鮮であり、現在のキャッシュを構築するために必要な呼び出しも実行します。
遅延がありますが、それは確かにクライアントへの変更の伝播に役立ちます。
問題は、クライアントがキャッシュ状態を維持することにより、余分なメモリを消費することです。
私はこれを画面ごとの状況で行っています。その画面が表示されなくなると、クライアントキャッシュは無効になり、その画面が再度呼び出されると、ローカルキャッシュが作成され、タイマーが開始され、ポーリングが開始されます。
お役に立てば幸いです。
エルナーニ
コメットのサポートは、 rocket-gwtプロジェクトを使用して GWT でも利用できます(これは、軽量コレクション、ドラッグ アンド ドロップなどの他の優れた機能も多数提供します)。コメットはRemotingパッケージによって提供されます。
これまでに試した中で最も有望な HTTP プッシュ (Comet) ライブラリは、StreamHub プロジェクトです。
StreamHub は、高度にスケーラブルな HTTP Comet およびリバース Ajax サーバーであり、プラグインやセキュリティ ポリシーの変更を必要とせずにライブ データを Web ブラウザーにプッシュできます。コメットまたはリバース Ajax と呼ばれる手法を使用して、ブラウザーに対して永続的な接続を開いたままにします。
それは、クライアントの状態を最新に保つために探しているものかもしれません。GWT アダプタープロジェクトもあります。