We need to persist per processinstance+nodeinstance data during the execution of a workitem. There are quite a few use cases for this:
1) The workitemhandler needs to store some state that it can use to build some additional guarantees in the face of server restarts/crashes.
E.g., in some FireMissileWorkItemHandler() I want to log the fact that the missile was already fired so that if the server crashed before jbpm hits the next persist point and the same process is restarted, the workitemhandler can lookup the state and see that it had already fired a missile. Of course this will not give us an exactly-once guarantee since the server can crash before it checkpointed but this way we give the workitem developers some more control.
2) A workitem handler generates some intermediate data that should be logged/persisted.
Here is the problem: the index for this data should be {processinstanceid, nodeid} since these are the only two things that will remain the same if the process instance is restarted after a crash. The workitemid that is available in a workitemhandler is regenerated if the workitem was executed again on a process restart. Now, within a workitemhandler I could not find any way to extract the node id of the currently executing node or the current node instance. Note that this is readily available for script tasks via kcontext.getNodeInstance(). I don't know why the same is not available for a workitem handler.
In addition to the persistence scenario, another use case for a node id in workitemhandler is that a workitem handler itself needs to generate a signal to a compensation handler. In this case, I want to say something like this in the workitemhandler code:
ksession.signalEvent("Compensate-" + current_node_id, null);
Again, it requires access to the current node id.
Is this an interesting scenario for the community as well? How did other folks resolve this?
Thanks