Once the child jobs are submitted, Oddjob's thread of execution continues
on out of this job. The state is set to ACTIVE and will continue to
change depending on the state of the child Jobs. The join
property can be used to hold the thread of execution until the
submitted jobs have finished executing - but it's use is discouraged.
See the property documentation below for more information.
The state of job, including its modification by the
stateOperator
property is identical to sequential
and is well documented there. Likewise with the transient property.
executorService | The ExecutorService to use. |
jobs | The child jobs. |
join | Should the execution thread of this job wait for the execution threads of the child jobs. |
name | A name, can be any text. |
stateOperator | Set the way the children's state is evaluated and reflected by the parent. |
stop | Read only view of the internal stop flag. |
transient | Is this job transient. |
Example 1 | Two jobs running in parallel. |
Example 2 | Two services started in parallel. |
Example 3 | Examples elsewhere. |
Configured By | ELEMENT |
Access | READ_WRITE |
Required | No. |
The ExecutorService to use. This will be automatically set by Oddjob.
Configured By | ELEMENT |
Access | WRITE_ONLY |
Required | No, but pointless if missing. |
The child jobs.
Configured By | ATTRIBUTE |
Access | READ_WRITE |
Required | No. Defaults to false |
Should the execution thread of this job wait for the execution threads of the child jobs.
This property re-introduces the default behaviour of parallel before version 1.0. Behaviour was changed to encourage the use of event driven configuration that didn't cause a thread to wait by using cascade or scheduling:trigger.
There are situations where this is really convenient as otherwise large reworking of the configuration is required. If possible - it is better practice to try and use the job state.
Configured By | ATTRIBUTE |
Access | READ_WRITE |
Required | No. |
A name, can be any text.
Configured By | ATTRIBUTE |
Access | READ_WRITE |
Required | No, default is ACTIVE. |
Set the way the children's state is evaluated and reflected by the parent. Values can be WORST, ACTIVE, or SERVICES.
Access | READ_ONLY |
Read only view of the internal stop flag. This flag is cleared with a reset.
Configured By | ATTRIBUTE |
Access | READ_WRITE |
Required | No, default is false. |
Is this job transient. If true state will not be persisted.
Two jobs running in parallel. Note that the order of execution of the two child jobs is not predictable.
<oddjob> <job> <parallel> <jobs> <echo>This runs in parallel</echo> <echo>With this which could be displayed first!</echo> </jobs> </parallel> </job> </oddjob>
Two services started in parallel. This might be quite useful if the services took a long time to start - maybe because they loaded a lot of data into a cache for instance.
<oddjob> <job> <cascade cascadeOn="COMPLETE"> <jobs> <parallel> <jobs> <bean class="org.oddjob.jobs.structural.ServiceManagerTest$Lights" id="lights"/> <bean class="org.oddjob.jobs.structural.ServiceManagerTest$MachineThatGoes" goes="ping" id="machine"/> </jobs> </parallel> <echo>The lights are ${lights.are} and the machine goes ${machine.goes}.</echo> </jobs> </cascade> </job> </oddjob>The cascade will execute the final job only once both services have started, and it will continue be in a STARTED after execution has completed.
Adding a SERVICES stateOperator property will mean that parallel is COMPLETE once the services have started and so the whole cascade shows as complete.
<oddjob> <job> <cascade> <jobs> <parallel stateOperator="SERVICES"> <jobs> <bean class="org.oddjob.jobs.structural.ServiceManagerTest$Lights" id="lights"/> <bean class="org.oddjob.jobs.structural.ServiceManagerTest$MachineThatGoes" goes="ping" id="machine"/> </jobs> </parallel> <echo>The lights are ${lights.are} and the machine goes ${machine.goes}.</echo> </jobs> </cascade> </job> </oddjob>
Examples elsewhere.