As tabelas JBPM devem estar em banco de dados separado?

Question

Existem duas opções ao configurar sua sessão JBPM.

1. Você pode colocar seus mapeamentos JBPM na mesma sessão de hibernato e, como resultado, ter suas tabelas no banco de dados com as tabelas de aplicativos.

2. Você pode colocar os mapeamentos JBPM em uma sessão de hibernato separada e tê -los em um banco de dados separado.

Vi um artigo que recomenda o método 1 e posso ver o porquê, porque ele permite que você tenha referências de chave estrangeira aos objetos de dados JBPM diretamente. O único problema que eu vi Pop -Up é se você tentar salvar o objeto JBPM enquanto um processo JBPM estiver em execução, você recebe um impasse no banco de dados.

Fora isso, qual método seria melhor e por que razões?

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...

Answer 3

We had a case where we decided to keep the jbpm database separate in order to be able to upgrade the version or maybe use another vendor when it would be necessary for different clients. As mentioned above, we ran into situations where we had to deal with separate hibernate sessions for a single operation in application level. In order to keep consistency in those conditions, we decided to use a tool called Atomikos