Hello Ami,
I spent a little (too much) time crawling through the code that manages state transfers between activities.
There is certainly a defect here, but it is very deep in the code and will require some real though to find a good solution.
The problem (in a nutshell) is a result of the fact that you join the flow from the notification (timer boundary event branch) back into the main flow.
This means, as soon as the first timer fires, a new "Concurrent" execution is created.
Concurrent executions are not removed until all flow lines are complete (i.e. in your example until Uster Task 2 is complete and the join is reached).
Because the execution is not deleted, the job's associated with the execution are also never deleted.
As far as I can tell in the few hours I spent yesterday, the execution is destroyed and marked inactive, but never actually deleted until the last concurrent execution completes. At that time, the whole set are deleted.
I have not (yet) tested, but I expect the version 6 engine will likely resolve this behavior as the PVM is no longer used and the mechanism used to track concurrent executions is completely overhauled.
That said, as a work around, have the flow path from the timer go to an end event after it completes it's processing. This way, there will be no concurrent executions and things will behave as you expect.
Hope this helps,
Greg
