设置 JBPM 会话时有两个选项。
您可以将您的 JBPM 映射放在同一个 Hibernate 会话中,从而将它们的表与应用程序表放在数据库中。
您可以将 JBPM 映射放在单独的 Hibernate 会话中,并将它们放在单独的数据库中。
我看过一篇推荐方法 1 的文章,我明白为什么,因为它允许您直接对 JBPM 数据对象进行外键引用。我看到弹出的唯一问题是,如果您在 JBPM 进程运行时尝试保存 jbpm 对象,您会在数据库上遇到死锁。
除此之外,哪种方法会更好,出于什么原因?
设置 JBPM 会话时有两个选项。
您可以将您的 JBPM 映射放在同一个 Hibernate 会话中,从而将它们的表与应用程序表放在数据库中。
您可以将 JBPM 映射放在单独的 Hibernate 会话中,并将它们放在单独的数据库中。
我看过一篇推荐方法 1 的文章,我明白为什么,因为它允许您直接对 JBPM 数据对象进行外键引用。我看到弹出的唯一问题是,如果您在 JBPM 进程运行时尝试保存 jbpm 对象,您会在数据库上遇到死锁。
除此之外,哪种方法会更好,出于什么原因?
It depends on the architecture you want to build.
If you want one centrally managed workflow component, where several different applications communicate with, a single database is the way to go.
Otoh, if workflow is specific to only some applications, it is better to keep the databases separated. That way, you can upgrade jBPM later in some applications and leave it as it is in others.
But you can also decide to have a separate DB for every app, even if there are a lot. This way, the runtime performance stays great since there is no huge table to manage)
As you can see, jBPM is very flexible in how to embed it into your architecture. So you will need to make the analysis for yourself and decide what's the best approach, taken into account current and future evolutions of your architecture.
将您的应用程序表和 jbpm 表放在 1 个数据库中允许您在单个事务中更新 jbpm 表和应用程序数据。例如,如果您想在 jbpm 中执行任务时更新应用程序数据的某些属性,这将非常有用。这有助于防止您的数据被损坏。否则,如果您提交 jbpm 事务,然后在提交应用程序数据事务时遇到问题,那么您将遇到一个非常大的问题......
我们有一个案例,我们决定将 jbpm 数据库分开,以便能够升级版本,或者在不同客户需要时使用其他供应商。如上所述,我们遇到了必须为应用程序级别的单个操作处理单独的休眠会话的情况。为了在这些条件下保持一致性,我们决定使用一个名为Atomikos的工具