Page History

...

• Should resource lock consistency be required for later job nodes in a job chain, i.e. if orders are created not for the begin of a job chain but for later job nodes, e.g. when using split job nodes, then assign the monitor /resource_lock_provider/request_resource_lock to the respective jobs:
  
   
   
• The repeat interval for which resource locks are checked is configured with the job manage_resource_lock of the resource lock provider.
  • The interval is 60s per default
  • The maximum number of retries is 1440 which defaults to a lifetime of 24 hrs. for a resource lock.
• The configuration is provided like this:
  
  Image Added 

Hints

• When requesting a resource lock by use of the request_resource_lock monitor then a delay of 3s is applied for the manage_resource_lock job to process the shadow order. A minimum delay is required to guarantee synchronization.
• 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.

Usage

• Add two orders to the job_chain1 job chain. 
  • Use an order ID in descending alphabetical order, e.g. "cba" for the order ID of the first order and "abc" for the order ID of the second.
• Both orders will be suspended at the first node of the job chain.
• After an idle timeout of 10s both orders will be moved to the next job node in the job chain. 
  • This time the orders will be processed in ascending alphabetical order.