Should JBPM tables be in separate database?

Question

There are two options when setting up your JBPM session.

1. You can put your JBPM mappings in the same Hibernate session, and as a result, have their tables in the database with the applications tables.

2. You can put the JBPM mappings in a separate Hibernate session, and have them in a separate database.

I have seen one article that recommends method 1, and I can see why because it allows you to have foreign key references to the JBPM data objects directly. The only issue that I have seen pop up is if you try and save the jbpm object while a JBPM process is running, you get a deadlock on the database.

Other than that, which method would be better, and for what reasons?

Answer 1

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.

Answer 2

Putting both your application and jbpm tables in 1 database allows you to update both jbpm tables and your application data in a single transaction. This is useful if, for example, you want to update some attribute on your application data when a task is performed in jbpm. This helps keep your data from getting corrupted. Otherwise if you commit your jbpm transaction and then run into an issue committing your application data transaction, you have a pretty big issue...