Page History

...

• Use Cases:
  • Consider the situation where a number of orders have been added to a job chain. These orders should then be serialized to guarantee that each order has completed the job chain before the next order starts.
  • Consider the situation that a number of job chains makes use of the same resource, e.g. by access to the same objects in a database. These orders should be serialized to guarantee that only one order of one job chain can access the resource at the same time. This use case applies e.g. to NoSQL databases that provide limited data consistency and therfore therefore require consistency to be provided at access level by a JobScheduler.
• Requirements
  • The solution implements resource locks that serialize access 
    • for orders of any number of job chains,
    • for any number of orders of the same job chain,
    • for orders that are added to any job node in a job chain.
  • Resource locks are persistent, i.e. they are restored to the same state after a JobScheduler restart.
  • Resource locks can by acquired by job chains that are executed 
    • with JobScheduler Agent instances including multiple Agents for job nodes of the same job chain (cross-platform).
    • with JobScheduler Master instances running standalone or in a Passive Cluster or Active Cluster.
  • Resource locks can be monitored and can manually be removed with the JOC GUI should the need arise.
• Delimitation
  • Limiting the number of concurrent orders in a job chain by use of the <job_chain max_orders="..."/> attribute works exclusively for the first job node. The solution offered by this article works optionally on any job node in a job chain.
  • This solution is focused on 
    • locks for complete job chains. For locks at job (task) level see Locks.
    • exclusive locks, shared locks are not considered.
  • Persistence of resource locks is limited to a predefined duration. The default value is 24 hrs. and can be configured for individual needs.
• Solution Outline:
  • The solution implements two parts represented by job chains:
    • Resource Lock Provider implements a job chain that accepts shadow orders for serialized access to resources. The job chain guarantees that only one order at a time is granted a resource lock. The job chain will suspend orders in originating job chains as long as a resource lock is blocked and will continue such orders when the resource lock becomes available. Any number of orders of the same or of different job chains can use the Resource Lock Provider job chain for serialization.
    • Resource Lock Consumer implements a sample job chain that makes use of a resource that should be accessed exclusively by one order at a time.
• References
  • SourceForge Forum Discussion Thread

  • Jira
    server SOS JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 6dc67751-9d67-34cd-985b-194a8cdc9602 key JS-402

...