悲観的ロックを行うには、次のようにできると書かれている grails のドキュメントに従いました。

これにより、保存が完了するまで計画インスタンスがロックされます。私の場合、次のように複数の計画を一度にロックしたいと考えています。

私はデフォルトでトランザクションであるgrailsサービスでこれを行っていますが、上記の行は期待どおりに機能していません.すべての行をロックせずstale state exception、同時トランザクションが実行されるとスローします.

読み取り時に複数の行をロックするにはどうすればよいですか?

詳細については、関連する質問を参照してください:データベースの古い状態の例外が発生する grails の同時トランザクション

EJB ビジネス Bean が JPA / エンティティ マネージャと連携し、すべてのトランザクションを管理する基本的な JSF/EJB/JPA Web アプリケーションがあります。

あれは：

Page.xhtml => PageBean.java => BusinessBean.java => Entity.java

Page.xhtml はエンティティの値を表示します。PageBean は、メソッド呼び出し (例: BusinessBean.getEntityById(x)) を介してビジネス層からエンティティを取得します。ビジネス Bean は、次のようにエンティティを取得します。

エンティティはプレゼンテーション層で編集され、フォームが送信されると、ビジネス Bean のバッキング ページ Bean からビジネス メソッドが呼び出されます。

これがこれを行うための最良の方法であるかどうかはわかりませんが、この方法に関するコメントを歓迎します。

ただし、中心的な問題はロックの管理に関するものです。要件は、ユーザーがエンティティの「編集」ページに入ると、エンティティがロックされ、他のユーザーが他の方法でエンティティを編集できないようにすることです (たとえば、そのエンティティの編集ページに入るなど)。

ページ バッキング Bean とビジネス ロジックをどのように構築して、これを可能にし、ユーザーがいなくなった場合に半永久的なロックを防ぐことができるでしょうか? トランザクションはビジネス層で開始および終了するため、ユーザーがプレゼンテーション層で対話している間、トランザクションをロックしてそのロックを維持する方法がわかりません。

私は現在、Rails 3 + postgresql で悲観的なロッキングを行っています。しかし、並行テストを行う手間をかけない限り、ロックが機能していることを確認する方法はないようです。コンソール経由でこれをテストする方法はありませんか?

例

たとえば、To Do リストなど、2 人の異なるユーザーがリストを更新できる Web アプリケーションを作成しています。高い競合は想定していないので、楽観的なロック メカニズムが最適に機能することに気付きました。

私はトランザクション分離レベルを見ていましたが、今は少し混乱しています。異なるトランザクション分離レベルでも同様の問題が解決されるようです。

これらの 2 つの異なる概念は互いにどのように関連していますか? できれば簡単な例で。

Infinispanユニット テストの 1 つに基づいて、簡単なテスト ケースを実行しています。私のテストCacheExceptionでは、クラスターでレプリケーションがタイムアウトしたときに受信することを期待しています。

私はペシミスティックなトランザクション ロックを使用していますが、この場合、何らかの理由で例外がスローされません。悲観的ロックにコメントすると、予想どおり例外が発生します。

悲観的ロックを有効にして例外を隠している理由とそれを修正する方法を誰かが理解するのを手伝ってくれますか?

更新: Infinispan 5.3.0.Final を使用しています。

アプリケーション

やあ、

複数のユーザーが共通のエンティティに対してアクションを実行するアプリケーション (J2EE/Hibernate/JPA) があります。

簡単にするために、このアプリケーションがGoogle docsのようなものだとしましょう。多くのユーザーが同時に更新できる共有ドキュメントです。

並行性を処理するためにオプトミスティック ロックを選択しました。

• 文は別個の実体です
• 複数のユーザーが同時に同じ文章を更新する可能性は低い
• その場合、いずれかのユーザーに「別のユーザーが同じ文章を編集しようとして申し訳ありません」というメッセージが表示されれば問題ありません。

バックグラウンド プロセス

ここまでは順調ですね。

しかし今、このアプリケーションにバックグラウンド プロセス(非常に高速なもの) を追加しました。彼らは定期的に変更を加えます（単語の出現を別の単語に置き換えるとしましょう）。

それらのジョブは失敗しても問題ありません。彼らのタスクは緊急ではなく、次回 (10 秒後) に同じタスクを試すことができます。

このような状況での楽観的ロックの問題は、1 人のユーザーがドキュメント全体に対してこれ以上長いアクションを実行できなくなることです。

実際、ユーザーがドキュメント全体 (すべての文) のフォントを変更し、このアクションにしばらく時間がかかる場合 (> 10 秒)、その間にバックグラウンド プロセスがいくつかの単語を変更し、より長いアクション (= ユーザーaction : change font) は同時アクセスで失敗します。

これは、ユーザーに次のメッセージを表示することはできません: 「いくつかの技術的なプロセスが同時に実行されていたため、アクションは失敗しました」

また、バックグラウンド プロセスは後で再試行できるため、むしろ失敗させます。

質問

楽観的ロックアプローチの中で、一部のアクション/アクターに対して悲観的ロックを設定するにはどうすればよいですか?

考えられる解決策

ユーザーにとって楽観的なアプローチを維持するために、次の解決策を考えました。

• 「ユーザー アクション」フラグを作成します。これは、任意のユーザーの任意のアクション中に設定されます。
• このフラグが「オフ」になるまで、ジョブは開始されません
• 実行中のプロセスの最後に、フラグがオンになっているかどうかを確認します。オンになっている場合は、このアクションをキャンセル/ロールバックします。

このようにして、ユーザーが何もしていないアイドル時にのみプロセスを実行できます。

ヘルプ

これは良いアプローチですか？ハイブリッド タイプのロックの優れたプラクティスに関する記事や議論は見つかりませんでした。