[jboss-user] [jBPM] - Re: jBPM5 - Can't Scale, Won't Scale

[Mauricio Salatino]

Mauricio Salatino [https://community.jboss.org/people/salaboy21] created the discussion

"Re: jBPM5 - Can't Scale, Won't Scale"

To view the discussion, visit: https://community.jboss.org/message/771738#771738

--------------------------------------------------------------
Hi Arnold,
Look below for some comments:

1. Everytime jBPM5 executes a process the database transaction updates the process instance info AND the session info, therefore:
1a. it's not scalable to use a single session to execute all processes, or you would suffer contention on the session info.
*Why do you want to use a single session?*
1b, it's not scalable to use a single session to execute all processes in a cluster, or the updated session info would have to be continually synchronised across the cluster.
*Yes, its madness to think that you can do that in a simple way. At this point having multiple sessions is a must if you want to divide where the execution can happen.*

2. When using BPMN2 events, jBPM5 only allows you to send events to the process instances within a single session at a time.  You need to maintain a list of all the sessions which have incompleted process instances(*), and loop through them all to send events.  Therefore:
2a. you should execute all processes in as few sessions as possible, to lessen the number of iterations through this loop.
*Or you can use a ESB or an lightweight integration framework to do that job like for example apache camel or Switchyard.*

3. jBPM5 persists BPMN2 timer info in the session info, but the session must be active (ie. loaded from persistence) in order for the timers to activate.  Therefore:
3a. when your application starts, you must load all sessions that have active process instances that have timers(**). 
*You can create a set of session with process that contains timers and a different set of sessions with the rest of the processes. I have an alternative solution for this kind of issues, which is to delegate those timers to an external component.* 
3b. you must not have the same session active in two different nodes of a cluster, or the same timers will expire around the same time
*Why do you want to have the same session in multiple nodes?* 
3c. when a node crashes, your application must detect this and reload the sessions that were active in the crashed node
*This is extremely related with your application, and yes you need to do your housekeeping*

4. If you start a process instance in a session, that process instance must always be executed in that session.
4a. when a node wishes to resume a process instance that was persisted, it must first (due to 3b) ask all other nodes if they have the session active, and if so instruct them to dispose it.  It can then load the session, load and resume the process.  All while preventing race conditions.
*Why do you want to have the session in multiple nodes? you should think in a different scheme where a retry mechanisms kicks in if something goes wrong. That retrying mechanisms can be an external component that keeps track of the sessions and know where and how to load them.* 
4b. when a node receives an event it must (due to 2) carry out all the processing in 4a for each session with active process instances.
*same as before*

*Hope it helps! 
*
--------------------------------------------------------------

Reply to this message by going to Community
[https://community.jboss.org/message/771738#771738]

Start a new discussion in jBPM at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2034]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-user/attachments/20121023/5e183a55/attachment-0001.html