一括更新機能の実装とそのトレードオフ
実装する機能は、ユーザーがアイテムを選択してデータ更新を一括で適用できるようにすることです。 選択した問題のリストを一括更新するJIRAの機能 と非常によく似ています。私の場合：
- 私はアイテムを繰り返します、
- アイテムごとに、アイテムを個別に更新するために使用される既存のメソッドを呼び出すだけです。
ビジネスロジックはJavaであるため、SQLレベル（つまり、SQLバッチ更新）ではこれを実行できないことに注意してください。
明らかに、パフォーマンスの場合、ユーザーが複数のアイテムを更新することを決定すると、速度が遅くなるため、速度=アイテムの数*トランザクションの速度が期待できます。 。したがって、実際には、アイテムを個別に更新することは、リストに単一のアイテムが含まれているリストを一括更新することと同じ速度である必要があります。 それはトレードオフなので、それは問題ありません。
私のその他の懸念はこれです：個別に更新するために使用されるメソッドは変更されず、番号に応じて複数回一括更新によって呼び出されるだけです選択したアイテムの;このメソッドは、トランザクションが完了するまで、関連するテーブルへのロックを取得します。これは事実上、更新するアイテムが複数ある場合、長時間ロックする原因になります。したがって、ユーザーは、ロックされたテーブルから取得するビューおよび検索ページを使用できません。これはトレードオフであり、上記で説明した最初のポイントほど受け入れられない可能性があります。
アイテムを個別に更新するための既存の方法の性質が実際にはロックを取得することであり、そのコードに触れることを想定していないことを考えると、私は矛盾しています。私はそのメソッドのみを再利用し、一括更新を実装するために複数回呼び出すことになっています。 この2番目のトレードオフは回避できないものですか、それは有効なトレードオフですか？
また、私はトランザクションとロックの専門家ではないことに注意してください。
あなたは確かにcan SQLを使用し、一括更新は、ORMレイヤーまたは複数の小さな更新の実行（オーバーライドトランザクションを使用）よりも優れたソリューション（パフォーマンスの点で）になる可能性がある領域の1つです。
これは、多くのネットワーク呼び出しと、より大きな更新ステートメントのコストです。
測定パフォーマンスの違いが必要ですが、ネットワーク全体のI/Oがより大きなボトルネックになっていると思います。
ロック/ txnsなどの観点から、これらの境界がどこにあるかを注意深く引き出します。 Txnのオーバーヘッドを減らすことができるかもしれません。 AOPスタイルのTxnsを使用すると、ここで役立ちます。つまり、必要なポイントにtxnの開始と終了を挿入し、それ以上は挿入しません。