私は、概念実証からパイロット プロジェクトに値する何かに移行中のプロジェクトに取り組んでいます。この開発フェーズの重要な改善点の 1 つは、メモリに保持され、定期的にファイルにダンプされるハッシュ テーブルを使用する現在の「持続性」メカニズムから、より従来型のデータベース バックエンドに移行することです。
アプリケーション自体は、ReSTful の原則を念頭に置いて設計されています。Jersey を使用してリソースへのアクセスを提供し、jQuery を使用してこれらのリソースをユーザーに提示し、基本的な対話 (作成、更新、削除) を有効にします。かなり簡単です。
リレーショナル データベースでサーバー側の状態を永続化するために、過去に JPA と Hibernate を使用して成功したことがあるので、この場合は当然の選択に思えました。モデル エンティティにいくつかのマイナーな変更を加えることで、基本的な読み取り、作成、および削除操作を適切な時間内に実行できるようになりました。ただし、更新操作はより困難であることが判明しました。
アプリケーションのクライアント側部分は、ユーザーがリソースを変更してから数秒後に変更をサーバーに自動的に送信します。さらに、ユーザーがホームページに戻る直前にリソースの最新バージョンをサーバーに送信するために押すことができる「保存して閉じる」ボタンがあります。
私の最初の問題は、管理対象エンティティをデータベースから、クライアントからの管理対象外オブジェクトで更新する方法でした。クライアントに送信されるデータは意図的にデータベース キーを省略しているため、管理されていないオブジェクトの要素を Hibernate オブジェクトに明示的に「マージ」することになるため、これは少し面倒でした。これは私の質問ではありませんが、これを行うエレガントな方法を知っている人がいれば、ぜひ聞いてみたいと思います。
私の 2 番目の問題、およびこの記事の目的は、前述の自動保存操作が行われているのとほぼ同時に「保存して閉じる」ボタンを押したときに発生します。多くの場合、楽観的ロック例外が発生します。これは、最初の更新操作がまだ処理されている間に、2 番目の更新操作が別のスレッドで処理されているためです。
リソースには、更新が処理されるたびに設定される「更新された」タイムスタンプがあるため、データベースへの更新は、何も変更されていなくても毎回保証されます。これ自体はおそらく問題ですが、修正した後でも、自動保存の進行中にユーザーが変更を加えてサーバーに送信できる「機会の窓」がまだあり、同じ問題を引き起こします.
この問題に対処するために私が考えることができる最も簡単なアプローチは、クライアント側の Javascript の一部を作り直して、そのクライアントからの未解決の「更新」操作が常に 1 つだけになるようにすることです。(別のクライアントがたまたま同じリソースを同時に更新した場合、楽観的ロック例外はまったく問題ないことに注意してください。) ただし、クライアントにこの制限を強制することは、ReST の精神から逸脱する可能性があることを懸念しています。ReSTfulアプリケーションの任意の時点で、特定のクライアントが特定のリソースに対する未処理の「更新」(PUT)リクエストを1つしか持たないと期待するのは合理的ですか?
これはかなり一般的なシナリオのように思えますが、それを処理する最善の方法について決定的な答えを見つけることができませんでした. 私が検討して破棄したその他のアイデアには、同じクライアントからのリクエストを (おそらく HTTP セッションに基づいて) 何らかの方法でシリアル化し、順番に処理されるようにすること、JPA/Hibernate ワーカー スレッドの更新の「キュー」を実装すること、および新しい "単一のレコードを更新するのではなく、最新のものを追跡しながら、リソースのバージョン"。
何かご意見は？クライアントでの「一度に 1 つの未処理の更新」という制限は合理的に見えますか、それともより良いアプローチがありますか?