古典的な生産者消費者問題に似たアプリケーションがあります。それを達成するために可能なすべての実装をチェックしたかっただけです。問題は-
プロセス A: データベースのテーブルに行を挿入します (プロデューサー)
プロセス B: テーブルから M 行を読み取り、読み取った M 行を処理後に削除します。
プロセス B のタスク: 1. M 行を読み取る 2. これらの行を処理する 3. これらの行を削除する
プロセス A の N1 インスタンス、プロセス B の N2 インスタンスが同時に実行されます。
各インスタンスは異なるボックスで実行されます。
いくつかの要件: プロセス p1 が (0,M-1) 行を読み取っている場合。プロセス p2 は、これらの行のロックを解放するまで p1 を待たずに、(M,2M-1) 行を読み取る必要があります。
DB をプロデューサーとコンシューマーの間のエクスチェンジャーとして使用するよりも優れた並列処理の方法があるに違いありません。なぜキューに入れませんか？Map/Reduce用に設計されたツール/フレームワークを確認しましたか。Hadoop、GridGain、JPPF はすべてこれを行うことができます。
同様の概念が Java.15 の ConcurrentHashMap で使用されています。処理中の行のリストは、個別に維持する必要があります。プロセスが DB と対話する必要がある場合、その行が別のプロセスによって処理されているかどうかを確認する必要があります。そうであれば、その条件で待機する必要があります。それ以外の場合は処理できます。このような場合、インデックスを維持すると役立つ場合があります
このアプリを実装すれば実際に手作りのキューを使っていると思います。この場合、JMS の方がはるかに優れていると思います。多くの JMS 実装が利用可能です。それらのほとんどはオープンソースです。
あなたの場合、プロセス A はタスクをキューに挿入する必要があります。プロセス B は でブロックされreceive()、N 個のメッセージを取得してから処理する必要があります。おそらく、キューから大量のタスクを取得する理由がありますが、実装を JMS ベースに変更すると、おそらくこれはまったく必要ないため、キューをリッスンしてメッセージをすぐに処理できます。実装はほとんど自明で、非常に柔軟でスケーラブルになります。プロセス A と B を必要な数だけ実行し、それらを別々のボックスに分散させることができます。
Amazon Elastic Map Reduce もご覧ください。