Thanks for your answer Kris! I have some questions about your suggestion.
When a process is in a wait state (human task), how would I know which session to load on task completion? Should I save the “case”-id in the task? Or better the session-id (id of KnowledgeSession)? Thus I don't have to persist a case-id – session-id mapping? Which field of a task would be appropriate for this and how can I set it dynamically on task creation?
About timers: How can I register a timer to this centralized session? And when would be the time to do this (a timer could be anywhere within a process)? What happens if the timer expires when the server isn't running? And what happens if a timer expires/fires in this centralized session? I think the process execution goes on within this centralized session. Thus if there is a rule task executed after the timer, we have the same problem (concurrent session access) again. Thus I have to load the session related to the case? But where and how can I switch process execution from one session to another?
The whole solution seems very complicated and error-prone to me. Another concern is about the human task service (we integrate it in-memory with a self-written connector): As I understand so far it uses local transaction and can't be integrated into JPA transactions. This is a show-stopper in a business application. Are there any plans to include JPA support?