Page History

...

• When requesting a resource lock by use of the request_resource_lock monitor then 
  • a delay of 2s is applied for the manage_resource_lock job to process the shadow order. A minimum delay is required to guarantee synchronization.
  • for shell jobs an error message will be added to the order log when the order is initially suspended. This message is not harmful and can be ignored. For API jobs no errors or warnings are raised. We recommend that you use the request_resource_lock job as a first job node of your job chain and use the monitor for subsequent job nodes only.
• The lifetime of a resource lock is limited by the duration that is covered with the setback interval of the manage_resource_lock job that defaults to 24 hrs.
• If you make frequent use of resource locks then you should consider to pre-load the manage_resource_lock job by use of the setting <job min_tasks="1"/> which results in the job to react immediately to incoming orders without having to load a JVM for each execution of this job.
• When operating the Resource Lock Provider job chain in a different location than the directory ./config/live/resource_lock_provider then the following settings have to be adjusted:
  • From the Resource Lock Provider the request_resource_lock monitor script specifies the path of the provider job chain.
  • From the samples for the Resource Lock Consumer
    • the job chains test_case_1 and test_case_1A both assign the job /resource_lock_provider/request_resource_lock as the first job node.
    • the job chain test_case_2 makes use of jthe obs job_step_1_resource_lock and job_step_2_resource_lock that are assigned the monitor location in /resource_lock_provider/request_resource_lock.

Usage

The following test cases are available with the Resource Lock Consumer sample job chain.

...

Test case 1: Check resource lock on first job step

• • The job chain test_case_1 makes use of the /resource_lock_provider/request_resource_lock job as the first job node.
  • No parameterization is used, therefore the scope of the resource lock is the current job chain that is forced to process order sequentially.
  • Adding multiple orders to this job chain causes all orders to be processed only after predecessor orders completed the job chain.
    • Start the orders test_case_1-1, ..., test_case_1-3 by use of JOC.
    • Add any number of new orders by use of JOC with the Add Order context menu.
Run test

Test case 1A:

...

Lock job chains

• • The job chain test_case_1A is a copy of test_case_1 but makes use of the same resource lock as test_case_1. 
  • The orders test_case_1A-1, ..., test_case_1A-3 use the parameter resource_lock with the value /resource_lock_consumer/test_case_1 therefore forcing orders for both job chains to be processed sequentially:
    • Start the orders test_case_1-1, ..., test_case_1-3 by use of JOC that will run for job chain test_case_1.
    • Start the orders test_case_1A-1, ..., test_case_1A-3 by use of JOC that will run in job chain test_case_1A but are synchronized with orders of job chain test_case_1.
Run test

Test case 2: Check resource lock on each job step

• • This test case is designed to prevent parallel execution of orders in a job chain independent from the job node that orders are started for.
  • The job chain test_case_2 makes use of the jobs job_step_1_resource_lock and job_step_2_resource_lock. Both jobs are assigned the request_resource_lock monitor. The above-mentioned initial job node request_resource_lock is not used as the individual jobs make use of the resource lock monitor.
  • Adding multiple orders to this job chain causes orders to behave sequentially as for test case 1:
    
    • Start the orders test_case_2-1, ..., test_case_2-3 by use of JOC.
    • Add any number of new orders by use of JOC with the Add Order context menu.