私の問題についてアドバイスをお願いしたいと思います。いくつかの計算（マルチスレッド環境）を実行し、テーブルにいくつかの挿入を実行するバッチがあります。バッチ挿入のようなことをしたいと思います。つまり、クエリを取得したら、たとえば1000クエリになるのを待ってから、バッチ挿入を実行します（1つずつ実行するのではありません）。
これにデザインパターンがあるのではないかと思いました。私は解決策を考えていますが、それは少し複雑です：
クエリを受け取るメソッドを作成します
それらをリスト（文字列および/またはステートメント）に追加します
リストに1000個のアイテムが含まれるまで実行しないでください
問題：どのように私は終わりを処理しますか？つまり、最後の999クエリは、1000に到達することはないので、いつ実行するのでしょうか。私は何をすべきか ？
5分ごとに起動してリスト内のアイテム数を確認するスレッドを考えています。彼が2回目を覚まし、数が同じである場合は、既存のクエリを実行します。
誰かがより良いアイデアを持っていますか？
データベースドライバは、バッチ挿入をサポートする必要があります。 これを参照してください。
サービスとデータベース間の通信が多すぎるために、システムがネットワークトラフィックを窒息させていることを確認しましたか？そうでなければ、あなたがそれを必要とすると確信するまで、私はバッチ処理について心配しません。
あなたはあなたの計画であなたが5分ごとにチェックしたいと言っています。それは永遠です。5分で1000アイテムを取得する場合は、バッチ処理は必要ありません。それは約3秒です。
バッチ処理を行う場合は、プロセスを2秒ごとにウェイクアップさせ、キューに入れられているものをすべてコミットします。5分待たないでください。0行をコミットする場合もあれば、10行をコミットする場合もあります...誰が気にしますか...このアプローチでは、任意のしきい値が満たされていないことを心配する必要はありません。
インサートは一度に1つずつ入ってくると思います。着信データが一度にnに入った場合、挿入がいくつ発生しても、すべての着信要求をコミットします。メッセージが何らかのメッセージングシステムとして受信される場合は、とにかく非同期であるため、バッチ処理について心配する必要はありません。高負荷の場合、着信メッセージは、それらを処理する容量ができるまで待機します。
すべてのアイテムが追加commitされたことを確認するために呼び出される一種のメソッドをそのAPIに追加します。また、最適なバッチサイズは20〜50の範囲です。その後、潜在的な利益は、ますます多くのステートメントに必要な簿記によって打ち負かされます。明示的には言及していませんが、もちろん、JDBCの専用バッチAPIを使用する必要があります。
それぞれが独自のスレッドで多数のライターを追跡する必要がある場合は、begin一種のメソッドも必要になり、呼び出された回数と比較して、呼び出された回数を数えることができますcommit。参照カウントのようなもの。ゼロに達すると、ステートメントバッファをフラッシュできることがわかります。
これは最も驚くべき概念であり、私は何度も直面しました。したがって、問題に応じて、バッチを作成していて、そのバッチには挿入のための1000以上のクエリがあります。ただし、同じテーブルに繰り返し挿入する場合。
このタイプの状況を回避するには、次のように挿入クエリを作成できます。-
INSERT INTO table1 VALUES（ '4'、'India'）、（ '5'、'Odisha'）、（ '6'、'Bhubaneswar'）
複数の値で1回だけ実行できるため、すべての値を任意のコレクション要素（arraylist、listなど）内に保持し、最後に上記のようなクエリを作成して1回挿入することをお勧めします。
また、SQLトランザクションAPIを使用することもできます。（Commit、rollback、setTraction（））など。
願っています、それはあなたを助けます。ではごきげんよう。