[Index]

parallel


A job which executes it's child jobs in parallel.

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.


Property Summary

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 Summary

Example 1 Two jobs running in parallel.
Example 2 Two services started in parallel.
Example 3 Examples elsewhere.

Property Detail

executorService

Configured ByELEMENT
AccessREAD_WRITE
RequiredNo.

The ExecutorService to use. This will be automatically set by Oddjob.

jobs

Configured ByELEMENT
AccessWRITE_ONLY
RequiredNo, but pointless if missing.

The child jobs.

join

Configured ByATTRIBUTE
AccessREAD_WRITE
RequiredNo. 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.

name

Configured ByATTRIBUTE
AccessREAD_WRITE
RequiredNo.

A name, can be any text.

stateOperator

Configured ByATTRIBUTE
AccessREAD_WRITE
RequiredNo, default is ACTIVE.

Set the way the children's state is evaluated and reflected by the parent. Values can be WORST, ACTIVE, or SERVICES.

stop

AccessREAD_ONLY

Read only view of the internal stop flag. This flag is cleared with a reset.

transient

Configured ByATTRIBUTE
AccessREAD_WRITE
RequiredNo, default is false.

Is this job transient. If true state will not be persisted.


Examples

Example 1

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>

Example 2

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>

Example 3

Examples elsewhere.


(c) R Gordon Ltd 2005 - Present