JBPMセッションの設定には2つのオプションがあります。JBPMテーブルは別のデータベースにあるべきですか？
あなたは同じHibernateセッションであなたのJBPMマッピングを入れ、その結果、アプリケーションのテーブルとデータベース内のテーブルを持つことができます。
JBPMマッピングを別々のHibernateセッションに配置し、それらを別々のデータベースに入れることができます。
私は方法1を推奨しています1件の記事を見てきましたし、それはあなたが直接JBPMデータオブジェクトへの外部キー参照を持つことができますので、私は理由を見ることができます。私がポップアップした唯一の問題は、JBPMプロセスの実行中にjbpmオブジェクトを保存しようとすると、データベースにデッドロックが発生することです。
それ以外の方法は、どのような理由で良いでしょうか？
ビルドするアーキテクチャによって異なります。
複数の異なるアプリケーションが通信する1つの集中管理ワークフローコンポーネントが必要な場合は、単一のデータベースを使用します。
ワークフローが一部のアプリケーションのみに限定されている場合は、データベースを分離した状態に保つ方がよいでしょう。そうすれば、後でいくつかのアプリケーションでjBPMをアップグレードし、他のアプリケーションと同じように残すことができます。
しかし、たくさんある場合でも、すべてのアプリに別のDBを割り当てることもできます。この方法で、管理するための何の巨大なテーブルが存在しないため、実行時のパフォーマンスは素晴らしいまま）
あなたが見ることができるように、jBPMはあなたのアーキテクチャにそれを埋め込む方法で非常に柔軟です。したがって、あなた自身で分析を行い、あなたのアーキテクチャの現在および将来の進化を考慮に入れて、最良のアプローチを決定する必要があります。
アプリケーションとjbpmテーブルの両方を1つのデータベースに入れると、jbpmテーブルとアプリケーションデータの両方を1回のトランザクションで更新できます。これは、たとえば、タスクがjbpmで実行されているときに、アプリケーションデータの一部の属性を更新する場合に便利です。これにより、データが破損するのを防ぐことができます。そうでない場合、jbpmトランザクションをコミットして、アプリケーションデータトランザクションをコミットする問題に遭遇した場合、かなり大きな問題が発生します。
本当に、私はこれを何度も実行しています。 – Zoidberg
jbpmデータベースを別々に保つことにしたバージョンをアップグレードするか、別のクライアントに必要なときに別のベンダーを使用することができます。上で述べたように、アプリケーションレベルでの1回の操作で、別の休止状態のセッションに対処しなければならない状況に遭遇しました。これらの条件に一貫性を持たせるため、Atomikosというツールを使用することに決めました。
システムごとにjbpmを使用していますので、簡単にコーディングできるようにすべてのデータベースを1つのデータベースにまとめておくことが理にかなっています。休止状態の関係の – Zoidberg