In jBPM 3.2.2, the JobSession.saveJob(Job) method looked like this:

session.saveOrUpdate(job);
if (job instanceof Timer)

{ Timer timer = (Timer) job; Action action = timer.getAction(); if (action != null && !session.contains(action)) session.save(action); }

However this resulted in a duplicate action being saved to the database every time a 'static' timer was created. Hence the above method was reduced to:

session.save(job);

This change would affect dynamic timers whose actions are dynamic as well, that is, not present in the process definition. Dynamic actions are a somewhat extraneous use case. Normally a dynamic timer would be assigned a named action from the process definition:

<process-definition>
<action name="normal" class="org.example.NormalAction"/>
<action name="exceptional" class="org.example.ExceptionalAction"/>
</process-definition>

Action action;
if (isNormalSituation)
action = processDefinition.getAction("normal"));
else
action = processDefinition.getAction("exceptional"));
timer.setAction(action);

If the action must be dynamic, it has to be saved manually under the new saveJob() behavior. Unlike the previous code snippet, where many dynamic timers share one static action, each timer is assigned a new action instance here:

Action action = new Action();
executionContext.getJbpmContext().getSession().save(action);
timer.setAction(action);

jBPM deletes timers after they execute, but the associated actions are NOT deleted because they are normally static. The leftover actions will remain in the database, unreachable from any other object. Junk data is thus the price of restoring automatic action saves.