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
Kris