Должны ли таблицы JBPM быть в отдельной базе данных?

Question

При настройке сеанса JBPM существует два варианта.

1. Вы можете поместить свои JBPM отображения в той же сессии Hibernate, и, как следствие, имеют свои таблицы в базе данных с таблицами приложений.

2. Вы можете поместить JBPM-сопоставления в отдельный сеанс Hibernate и разместить их в отдельной базе данных.

Я видел одну статью, которая рекомендует метод 1, и я могу понять, почему, потому что это позволяет вам иметь внешних ключей ссылки на объекты JBPM данных напрямую. Единственная проблема, с которой я столкнулся, заключается в том, что если вы попытаетесь сохранить объект jbpm во время работы JBPM, вы получите тупик в базе данных.

Помимо этого, какой метод был бы лучше и по каким причинам?

Answer 1

Это зависит от архитектуры, которую вы хотите построить.

Если вам нужен один управляемый централизованно обработанный компонент рабочего процесса, с которым взаимодействует несколько разных приложений, единственная база данных - это путь.

Otoh, если рабочий процесс специфичен только для некоторых приложений, лучше хранить базы данных отдельно. Таким образом, вы можете обновить jBPM позже в некоторых приложениях и оставить его как есть в других.

Но вы также можете выбрать отдельную БД для каждого приложения, даже если их много. Таким образом, производительность во время выполнения остается отличной, поскольку нет огромной таблицы для управления)

Как вы можете видеть, jBPM очень гибко встраивает его в вашу архитектуру. Таким образом, вам нужно будет сделать анализ для себя и решить, что лучше всего подходит, учитывая текущие и будущие эволюции вашей архитектуры.

Answer 2

Ввод таблицы приложений и jbpm в 1 базу данных позволяет вам обновлять таблицы jbpm и данные приложения в одной транзакции. Это полезно, если, например, вы хотите обновить некоторый атрибут данных приложения, когда задача выполняется в jbpm. Это помогает предотвратить повреждение ваших данных. В противном случае, если вы зафиксируете транзакцию jbpm и затем выполните пробную транзакцию, у вас есть довольно большая проблема ...

Answer 3

У нас был случай, когда мы решили сохранить отдельную базу данных jbpm, чтобы иметь возможность обновить версию или, возможно, использовать другого поставщика, когда это потребуется для разных клиентов. Как упоминалось выше, мы столкнулись с ситуациями, когда нам приходилось иметь дело с отдельными сеансами спящего режима для одной операции на уровне приложения. Чтобы сохранить согласованность в этих условиях, мы решили использовать инструмент под названием Atomikos