There is a REST interface (it is part of the console- jbpm-gwt-console-server) that provides access to some of operations on the session, so in fact you could start the process or set variables fir a given process. I am not sure what you mean by:
1.b) Add facts to a running stateful process
do you want to add facts to the session (working memory) or add/set process variables on process instance? The second is possible through the REST interface.
Regarding proper requests distribution, that depends on quite many aspects of your design. For instance, you could set it up to bind session (jbpm state full session) into http session life cycle. Whenever new request comes in, and it was issued by the same caller (is with http session id) you can distribute it to the right server based on load balancer strategy with sticky session attribute. That would mean that you will have a dedicated state full session per http session, so you need to make sure they will be disposed properly, this is what I meant by binding it to http session life cycle, when http session will be invalidated state full session would be disposed.
1) Yes, I meant adding facts to working memory
2) Sticky session is not an option, since, all communication with jBPM webservice will be by events from other systems. Any ideas for this case?
1 of 1 people found this helpful
Alright, now we have bit more information
If I understand your case properly, once a process is started the web service will return at least process instance id to the caller for further reference, correct? If so, you could do one of the following:
- return session id as well with process instance id so it can be referenced for subsequent calls
- maintain a map of process instance id to session id on jBPM service side (either in db or distributed cache)
That would mean that each call should dispose the session. Next calls will load the session based on provided session id regardless of what server the request is being processed on.
What do you think about it?
Does session.dispose() save the state? If that is the case, then yes, I could use it instead of the background jobs solution I scribbled in OP.
yes, session state is saved once you enable persistance (JPA by default).
btw, if find this answered please mark it as such so other can benefit from it.
I marked one as helpful. I wasn't sure if session.dispose() call saves the state or deletes the state from database. When will the state be deleted from database when JPA is enabled.
State is saved on transaction boundaries, by default at each node (enter and exit) - afaik. dispose is releasing resources in memory.
I did not mean to mark my replies as answered but the question itself