Page History

...

Yes, the order will be enqueued with a state for Job2. This applies to both orders and jobs:

1. Persistence of Enqueued enqueued Orders

   If an order is enqueued (either for one time processing without any run time or with a run time for repeated processing) then JobScheduler stores this order in the database (in the table SCHEDULER_ORDERS) should a database be used. This behavior is independent from use of "Managed Jobs" and applies for all orders.

   Changes to the order state that reflect the proceeding of the order in the job chain to the next job node are equally updated in the database. To be transactionally correct the order state is updated after

   • The the method spooler_process() is left completed for jobs that make use of the API via <script language="Java|java:JavaScript"/>
   • An an executable file has been terminated that was started via <processvia  via <script language="shell"/>

   If JobScheduler is killed while an order is processed then the order with it's current state, i.e. the input level of the current job node, will be restored from the database on the next start of the JobScheduler.

2. Persistence of Enqueued enqueued Jobs

   This is handled in the following way:

   • Tasks that are running and are killed due to killing JobScheduler main task are not restarted on scheduler startup (as JobScheduler cannot decide if it's decent to re-execute this job regarding run times and corresponding begin and end time slots etc.).
   • Should a task be enqueued for a future date, e.g. with <start_job job="..." at="now+3600"/><params/></start_job> or the respective API methods then this task's start time is reflected in the database (in the table SCHEDULER_TASKS). For orders and jobs JobScheduler will read the respective tables on startup and enqueue the respective orders and task to the given start time.