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