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

Kris Verlaenen do-not-reply at jboss.com
Mon Mar 11 15:27:11 EDT 2013

Kris Verlaenen [https://community.jboss.org/people/KrisVerlaenen] created the discussion

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

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

> > *If you only have one session, there would be no contention as the ksession would solve this* 
> I did not know this and this is could be the root of my misunderstanding.  But I can't understand how the ksession could solve this.  If process instance A executes in transaction Ta and process instance B executes in transaction Tb, and both transactions change the session info - which is simply a JPA entity - how do the two process instance executions NOT serialise?
The engine will make sure  request a is completed before starting request b.

> In fact, I can see how these sessions might be useful for Drools users, but from the point-of-view of a jBPM user - who just wants to execute processes - it's hard to see what the concept of sessions gives you?  If you just want to execute business processes, why should you care about "sessions"? 
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


Reply to this message by going to Community

Start a new discussion in jBPM at Community

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-user/attachments/20130311/71a21f07/attachment-0001.html 

More information about the jboss-user mailing list