Clever Geek Handbook

Do JBPM tables have to be in a separate database?

There are two options when setting up a JBPM session.

  • You can map JBPM mappings in a single Hibernate session and, as a result, have your tables in the database with your application tables.

  • You can map JBPM mappings in a separate Hibernate session and have them in a separate database.

I saw one article that recommends method 1 and I can see why because it allows you to directly reference foreign keys to JBPM data objects. The only problem I have is that if you try to persist the jbpm object while the JBPM is running, you get a dead end in the database.

Also, which method would be better, and for what reasons?

+2


source to share


3 answers


It depends on the architecture you want to build.

If you need a single centralized workflow management component that multiple different applications interact with, a single database is the way to go.

Otoh, if the workflow is specific to only some applications, it is better to leave the databases separate. Thus, you can update jBPM later in some applications and leave it as it is in others.



But you can also choose a separate database for each application, even if there are many. This way, runtime performance remains excellent as there is no huge table to manage)

As you can see, jBPM is very flexible in embedding it into your architecture. Therefore, you will need to do the analysis for yourself and decide which is the best approach given the current and future changes to your architecture.

+3


source


Putting your app and jbpm tables in 1 database allows you to update both the jbpm tables and your app data in a single transaction. This is useful if, for example, you want to update some application data attribute when a task is executed in jbpm. This helps prevent damage to your data. Otherwise, if you commit the jbpm transaction and then do a trial operation on the application data transaction, you have a pretty big problem ...



+1


source


We had a case where we decided to keep a separate jbpm database in order to be able to update the version, or perhaps use a different vendor when different clients need it. As mentioned above, we ran into situations where we had to deal with separate hibernation sessions for a single application-level operation. To maintain consistency under these conditions, we decided to use the Atomikos tool

+1


source






More articles:


All Articles