JBossDeveloper

Hi,

I'd also like some clarification on this part where you mentioned :

A session is the runtime interface to talk to the engine, so you do need it.  But you are right, when you don't need any rule-related persistence etc., you probably don't need some of this "advanced" session management.  In situations like this, the two most common architectures are:

* Session per request: if your session doesn't contain any state and you don't use any timers, you can just instantiate a session on request and dispose it afterwards

   -> session mgmt is fairly simple, just create / dispose every time

* Singleton session (or as extension N sessions): you have a service that reuses the same session(s), and keeps these sessions alive at all time (to support timer execution), possibly distributed across a cluster of nodes

   -> no disposal of sessions

 

Kris

Does this mean that if I do not have any rule-related persistence, just using the session to start process instances and signal events it is alright to use a singleton session?

Eg. Hundreds or thousands of process instances executed in the same session will not have any ill effects?

Or I should stick to the session per request and dispose it afterwards. (provided the process instance can continue execution in a separate session)

Thanks

Correct, the number of process instances that are currently active isn't all that important, as they are only loaded into memory if they need to move forward.  Having thousands of process instances managed by a singleton session is possible as long as that session is capable of handling the load (i.e. the requests per second that are necessary), as typically it only means that there are thousands of rows in the database (one per process instance) but only a few of those will be in memory at all times. 

For example, if every process instance only changes typically once a day, then one session can handle that.  If they all change every second, you'll need to distribute your requests amongst multiple ksessions, as one simply won't be able to handle the load.

Kris

Hi Kris,

but what is about large enterprise usage, where were a singleton session can't handle the load any more?

I'm thinking of processes with thousands of instances getting processed massive in parallel, whereby long waiting ,e.g. for human interaction, is an "execptional" flow.

I have seen these scenarios e.g. in month/quarter/year-end calcuations, when the same process get started on every account/costcenter/stock-item/etc.

I would be very helpful to get a blue-print (incl. quickstarts, etc.) as documentation how to setup large high available and scalable environment.

Cheers,

Carsten

Carsten,

If you are using jBPM5, the most common answer is to have multiple of these sessions running in parallel (on multiple nodes, so each node typically might have one or a few sessions).  This way, the load can be distributed amongst all nodes.  For HA, should one node go down, the other nodes should temporarily be able to handle the load until that node is back up.  Or the sessions could be restored on a different node for example.

When looking at jBPM6, we've made several improvement, especially related to timers and sessions management.  In that case, you would simply deploy the session manager on each node in the cluster, and it will manage sessions for you.

Kris