Истинная параллельная обработка в jBPM - PullRequest
0 голосов
/ 12 января 2010
need to achieve:


Обработка нескольких задач

<fork name="customFork" >
  <transition to="task1" />
  <transition to="task2" />        
  <transition to="task3" />
       ... ... ...
  <transition to="taskN" />         
</fork>

Решение jBPM должно выполнять задачи параллельно, а не, как это делается по умолчанию, последовательно.

Я прочитал документацию jBPM, в которой предлагается использовать async="true" на узлах / задачах, однако неясно, как именно точно это должно быть реализовано. Одним из предложений было сохранить его в БД и отправить задачи в очередь JMS, а не заниматься пользовательским многопоточным управлением. Однако мне показалось слишком странным, что у jBPM нет простого решения для этого.

Я надеюсь, что кто-то здесь докажет, что я неправ, и покажет мне простое и элегантное решение с jBPM 3.2.6 [поскольку это последняя версия, поддерживаемая Red Hat]

Спасибо.

1 Ответ

4 голосов
/ 17 ноября 2010

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

Это обычный компромиссный дизайн, когда речь идет о двигателях BPM. Вы избегаете всех ошибок управления параллелизмом (взаимоблокировки, условия гонки, голодание, проблемы согласованности ...) с помощью одного потока выполнения для каждого экземпляра процесса. Предполагается, что бизнес-процессы носят длительный характер, но также ожидают, что какое-то событие произойдет большую часть времени, и сами по себе не должны требовать значительных вычислительных ресурсов. Таким образом, ЦП никогда не должен быть узким местом при выполнении одного экземпляра процесса.

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

...