次のシナリオでは、どの製品/プロジェクトが役に立ちますか?
明白な答えはもちろんデータベースかもしれませんが、私たちは Seam を使用しており、Seam-bean 内にトランザクションをネストする良い方法がないように思われるので、構成に夢中になる必要がない方法を見つける必要があります。 (EJB:s を使用しようとしましたが、persistence.xml は後できれいではありませんでした)。したがって、Seam がネストされたトランザクションをサポートするまで、この問題を回避する別の方法が必要です。
これは基本的に、詳細が必要な場合のシナリオと同じです: https://community.jboss.org/thread/182126。
何か案は？
分散ジョブ管理を行う必要があるようです。
現実には、Java EE の世界では、MoM [メッセージ指向ミドルウェア] のように、最終的にキューを実行する必要があります。Seam は JMS で動作し、パブリッシュ キューとサブスクライブ キューを持つことができます。
代替手段を探したいと思うかもしれない場所は Akka です。透過的なアクター/エージェント モデルを使用して、複数のマシンにジョブを分散できます。つまり、エージェントは、同じインスタンス上にあるか、互いにネットワークを介しているかに関係なく、互いに協力することができ、それを実現するために大量のコードを記述したり、メッセージの上下を特別に処理したりする必要はありません。鎖。
Akka が目指しているもう 1 つのことは、監督の概念、別名 Go Ahead and Fail、または Let it Crash です。これは、システムに障害が発生した場合に備えて設計し、回復力を持たせる手段を用意する必要があるという考え方です (通信会社が何年も前から行ってきました)。
最後に、Java の世界におけるその他のオプションの仕事の状況は悲惨です。何年も Seam を使用しています。それは素晴らしいことですが、彼らは仕事のために Quartz をサポートすることに決めました。これは役に立ちません。
Akka も Netty に基づいて構築されており、同時実行性とパフォーマンスの点で非常にクレイジーなことを行います。
[TypeSafe の従業員ではありません、ところで…]