As far as i understand jbpm's single threaded execution model, when I make a call to jbpm which changes something, the call does not return while there are some tasks to execute. On the other hand the user guide 6.2 says (figure 24.1 and below) that in some cases jbpm console shows running service tasks and allows to cancel them. How is it possible? The task is started in some transaction and should not be visible to other transactions; otherwise we could observe phantoms if the transaction which executes the task rolls back. And, as the call does not return while there is work to do, the transaction does not commit, so the fact of task's execution should not be seen by others. What is wrong with my reasoning?
Okay now I know what is going on. Userguide hints on that, but their phrasing "The engine will wait for the completeWorkItem(...) method to return before continuing execution." made me mistake completeWorkitem for executeWorkitem. After all, completeWorkitem does not return to jBpm (it's not called by jBpm)! ExecuteWorkitem does. So jBpm cannot wait for "return from completeWorkitem", it can only wait for call to it. In other words, "before continuing execution" does not mean a thread-blocking call: the call returns but the jBPM process will not execute other nodes till someone calls completeWorkitem().
So, actually it' very simple. Suppose I did some call to jBpm which made it execute process and enter service task node. On node enter, jBpm runs executeWorkitem and of course my calling code does not get control until executeWorkitem finishes. If it is performing something heavy, well, too bad and this transaction will not commit until this heavy thing is finished, so no one can see it in mid-air. But if it's returning at once (either after called completeWorkitem, or after starting a thread which will call it later), jBpm will once again look if there are some nodes ready for entry. If there are no such nodes (in case completeWorkitem was not yet called), process enters wait-state and execution returns to rthe caller, so now if the caller commits (or if jBpm did not join any transaction but started its own), everyone will be able to see that the service task was started but was not finished.