JBPMセッションを設定する場合、2つのオプションがあります。
JBPMマッピングを同じHibernateセッションに配置することができ、その結果、それらのテーブルをアプリケーションテーブルとともにデータベースに含めることができます。
JBPMマッピングを別のHibernateセッションに配置し、別のデータベースに配置することができます。
方法1を推奨する記事を1つ見ましたが、JBPMデータオブジェクトへの外部キー参照を直接持つことができるため、その理由がわかります。私が見た唯一の問題は、JBPMプロセスの実行中にjbpmオブジェクトを保存しようとすると、データベースでデッドロックが発生することです。
それ以外に、どちらの方法が良いでしょうか、そしてどのような理由で？
構築するアーキテクチャによって異なります。
複数の異なるアプリケーションが通信する1つの集中管理されたワークフローコンポーネントが必要な場合は、単一のデータベースが最適です。
おと、ワークフローが一部のアプリケーションにのみ固有である場合は、データベースを分離しておくことをお勧めします。そうすれば、後で一部のアプリケーションでjBPMをアップグレードし、他のアプリケーションではそのままにしておくことができます。
ただし、アプリがたくさんある場合でも、アプリごとに個別のDBを用意することもできます。このように、管理する巨大なテーブルがないため、ランタイムパフォーマンスは優れたままです）
ご覧のとおり、jBPMは、アーキテクチャに組み込む方法に非常に柔軟性があります。したがって、アーキテクチャの現在および将来の進化を考慮して、自分で分析を行い、最適なアプローチを決定する必要があります。
アプリケーションテーブルとjbpmテーブルの両方を1つのデータベースに配置すると、1つのトランザクションでjbpmテーブルとアプリケーションデータの両方を更新できます。これは、たとえば、タスクがjbpmで実行されるときに、アプリケーションデータの属性を更新する場合に役立ちます。これにより、データが破損するのを防ぐことができます。そうしないと、jbpmトランザクションをコミットしてから、アプリケーションデータトランザクションのコミットで問題が発生した場合、かなり大きな問題が発生します...
バージョンをアップグレードしたり、別のクライアントで必要になったときに別のベンダーを使用したりできるようにするために、jbpmデータベースを分離しておくことにした場合がありました。上記のように、アプリケーションレベルでの単一の操作に対して個別のHibernateセッションを処理する必要がある状況に遭遇しました。このような状況で一貫性を保つために、Atomikosというツールを使用することにしました。