4.3.8. Asynchronous Executions (Jobs)
| 4.3. Services |

### 4.3.8. Asynchronous Executions (Jobs)

To optimize the execution, Orchestra splits the execution in small steps. A job represents a step of an execution. It can be executed in parallel with other jobs. Jobs are grouped in two sets: messages, which can be executed immediately, and timers, whose executions are scheduled at a precise date.

Timers are used for the BPEL statements "wait" and "onAlarm".

Messages are used for the BPEL statements "receive", "onEvent", "onMessage" and "invoke".

Orchestra uses the PVM Job executor framework to handle jobs. Jobs are created using either the timer session service or the message session service. The job executor then fetches the job from the database and perform the instructions contained in the job.

#### 4.3.8.1. Timer session

A timer session service is required to schedule timers in the PVM. Its definition in the environment is the following :

    <timer-session retries="5"/>

The timer session retries (optional) attribute can be used to define how many times the job will be retried before it becomes dead (see Section 4.3.8.4, “Dead jobs”).

#### 4.3.8.2. Message session

A message session service is required to schedule messages in the PVM. Its definition in the environment is the following :

    <message-session retries="5" use-fair-scheduling="false"/>

The message session retries (optional) attribute can be used to define how many times the job will be retried before it becomes dead (see Section 4.3.8.4, “Dead jobs”).

The message session use-fair-scheduling (optional) attribute can be used to define ifthe jobs should be executed with the same priority or if the jobs of older instances should be executed first.

#### 4.3.8.3. Job Executor

The job executor fetches the jobs to execute from he database, and then executes the job.

Default implementations of the job executor uses a thread pool to execute jobs in parallel.

There are two default implementations of the job executor:

- an implementation using a thread pool with a fixed size. This service is defined in the environment file with the following line :

      <job-executor threads='10' auto-start='false' />

  The number of thread is defined by the threads attribute. This implementation is the default implementation.

- an implementation using a thread pool with a variable size (based on java.util.concurrent.ExecutorService). This service is defined in the environment file with the following line :

      <job-executor type='jdk' auto-start='false' />

Optional attributes can be defined in the environment to configure the job executor service:

- command-service: name of the command service to use to execute jobs. Only necesssary if more than one command service exists.

- dead-job-handler: name of the command service to use to handle dead jobs. Only necesssary if more than one dead job handler exists.

- idle: polling interval of the job database (in milliseconds). Note that the job executor is notified of job added by message and timer session services. Polling is just to check no notification has been missed.

- lock: before a job is executed by a job executor thread, the thread locks the job to be sure no other threads executes the same job. The lock attribute specifies the duration of the lock (in milliseconds). When the lock expires, a new thread can execute the job again (can happen if a job executor thread dies unexpectedly).

- limit-job-per-instance: specifies if jobs of a process instance should be executed sequentially. If this attribute is set to false, jobs of the same instance can be executed in parallel.

#### 4.3.8.4. Dead jobs

If an exception occurs during a job execution, the job executor will decrement the retry counter of the job. While the retry counter is positive, the job executor will pick the job and try to execute it again.

When the job retry counter is zero, the job executor will not execute the job again. The job becomes a dead job.

If a dead job handler exists in the environment, it will be executed.

The default retry counter value for a job can be set in the message session configuration.

##### 4.3.8.4.1. Dead Job Handler (DJH)

DJH are executed after a job retry counter has reached zero. Orchestra provides following implementations in the package org.ow2.orchestra.services.handlers.impl:

- ExitInstanceDeadJobHandler : exits the BPEL instance which has faulted.

- ThrowBpelFaultDeadJobHandler : throw a BPEL fault {http://orchestra.ow2.org}jobExecutionFault to the BPEL instance which has faulted. The fault can be handled by a catch activity.

By default, the ExitInstanceDeadJobHandler is enabled.

##### 4.3.8.4.2. Interacting with dead jobs

The management API provides methods to find dead jobs and to reset the retry counter of a job to a specified value.

If you want to manage the dead jobs manualy, you need to disable the Dead Job Handler.

Refer to Section 6.1, “Orchestra APIs” for more information on how to use the APIs.

#### 4.3.8.5. Invoke Executor

The invoke executor executes external web services calls. Invoke are executed by a separate thread pool. The thread is hold until the web service response is received.

Default implementation of the invoke executor uses a thread pool to execute invoke in parallel.

The default implementation of the invoke executor use a thread pool with a fixed size. This service is defined in the environment file with the following line :

    <invoke-executor threads='10' />

The number of thread is defined by the threads attribute. This parameter defines the maximum number of invoke that can be executed simultaneously.

4.3.7. Command service |  | 4.3.9. Finished instance handler (FIH)