With current version 6.6.0 getVariablesLocal() and getVariablesLocal(name,true) return still the variabel after exectuion is deleted, but getVariablesLocal(names,false) not anymore. is there a specific reason?
How are you deleting the execution? Looking in the code, variables that are local should be deleted when passing through the ExecutionEntityManager.
When catching a critical boundary event e.g. on a task, the executions are deleted in org.flowable.engine.impl.bpmn.behavior.BoundaryEventActivityBehavior.executeInterruptingBehavior(ExecutionEntity, CommandContext)#deleteChildExecutions via org.flowable.engine.impl.persistence.entity.ExecutionEntityManagerImpl.deleteRelatedDataForExecution(ExecutionEntity, String)
As part of this also the Variables are deleted.
In our case we listen to the ACTIVITY_CANCELLED flowable event which will be dispatched after the deletion. In there we want to log that the task has been cancelled with additional data stored as local variable on the task execution. Our read access happens via extension of org.flowable.engine.impl.cmd.GetExecutionVariablesCmd. The observation was that execution.getVariablesLocal() as well as execution.getVariablesLocal(variableNames, true) was still able to access the variable while execution.getVariablesLocal(variableNames, false) was not; one accessing the db in the end while the others are using a cache.
In flowable 5 it looks like the sequence was different, first the event was dispatched, then the execution was deleted.
Our solution was to hook into the EntityManager and dispatch a custom event about the cancellation while the execution is not yet deleted.
What is the best solution here? Was the sequence changed for a reason and is considered to stay like this? Assumption currently is that it stays this way and accessing an already deleted variable should not be possible anyway, how can we continue here? A new flowable event like ACTIVITY_ABOUT_TO_BE_CANCELLED? Any other possibility?
Yes, that’s is most likely not going to change.
It shouldn’t be possible (unless through the cache). When the activity is cancelled, the related execution is gone (and its local variables).
We don’t have any such event in other places, so that wouldn’t be very consistent.
One option that probably cleaner is overriding the BoundaryEventActivityBehavior through the activityBehaviorFactory and to explicitely implement the logic as you describe (which is not common logic) in the executeNonInterruptingBehavior method.