1

JBOSS7 および JPA2 + Hibernate で Java EE 6 を使用しています。私のクライアントには、REST API を提供します。

私の懸念は、リソースが同時に変更されないようにする方法です。頻繁に発生する必要がありますが、発生した場合は適切な処理を確実にしたいと考えています。

これまでの私のアプローチ：

  1. Map<String, ReentrantLock>ロックを格納します。(私の ID は常に UUIDs です) マップにない場合、ロックはオンデマンドで作成されます。このアプローチでは、同時アクセスがブロックされ、他のスレッドがリソースをロックしようとする時間を制御できることが気に入っています。

  2. JPA2 楽観的ロックを使用します。

どちらをお勧めしますか？それとももっと良いアプローチがありますか？

4

1 に答える 1

3
  1. エラーが発生しやすいように見えますが、スケーリングできない可能性があります。私はそのようなデザインを見たことがなく、それを思いとどまらせます。
  2. 楽観的ロックを使用したトランザクションは実行可能なオプションです。この場合、一部のトランザクションが失敗する可能性があり、エラーに対処して再試行する必要があります。
  3. 悲観的ロックを使用したトランザクションは、別の実行可能なオプションです。1) に似ていますが、データベースを使用して操作をロックおよび順序付けします。AFAIK、JPAは悲観的ロックもサポートしています。それ以外の場合は SELECT FOR UPDATE、明示的に行ロックを取得するために (ほとんどの DBMS でサポートされています) を使用できます。デッドロックを回避するために、ロックが一貫した順序で取得されるスキームを理解していることを確認してください。

2 ～ 3 のいずれかを選択するかどうかは、ユース ケースによって異なります。たとえば、競合が多いと予想されるかどうか、失敗したトランザクションを簡単に再試行できるかどうかなどです。

于 2012-09-04T06:43:32.833 に答える