[
https://jira.jboss.org/jira/browse/JBPM-2603?page=com.atlassian.jira.plug...
]
Alejandro Guizar updated JBPM-2603:
-----------------------------------
Restored automatic timer action saving with:
session.save(job);
if (job instanceof Timer) {
Timer timer = (Timer) job;
Action action = timer.getAction();
if (action != null && action.getId() == 0)
session.save(action);
}
The code for saving an action had been removed because it saved a duplicate that prevented
the process definition from being deleted in JBPM-2036. Changing the guard condition from
!session.contains(action) to action.getId()==0 avoids saving a duplicate in the following
situation:
ProcessDefinition processDefinition =
ProcessDefinition.parseProcessDefinition("...");
jbpmContext.deployProcessDefinition(processDefinition);
newTransaction();
ProcessInstance processInstance = new ProcessInstance(processDefinition); //
processDefinition is now detached!
With the process definition and its related object graph -including the action- detached,
session.contains() returns false for the action even when the action is persistent. By
checking the id instead, the job session can tell the action is saved already even if it
is detached.
Restore automatic save of timer actions
---------------------------------------
Key: JBPM-2603
URL:
https://jira.jboss.org/jira/browse/JBPM-2603
Project: jBPM
Issue Type: Bug
Components: Runtime Engine
Reporter: Alejandro Guizar
Assignee: Alejandro Guizar
Fix For: jBPM 3.2.9
Original Estimate: 0 minutes
Remaining Estimate: 0 minutes
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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira