Maintaining Background Processes Overview

Each new background processes require the creation of two new classes: a BatchJob and a ThreadWorker. These classes fit into the "master-worker" pattern used by the background process runtime infrastructure to overcome the throughput limitations encountered by single-threaded processes. By splitting work among many concurrent threads often on multiple physical nodes background processes can achieve excellent scalability and react to changing work demands without additional programming. In this pattern:

• A BatchJob is responsible for determining the work to be processed for a batch run and then splitting that work into pieces that each ThreadWorker will process. When running a single process, a single BatchJob object is instantiated by the framework. The framework then makes calls to the BatchJob instance at the appropriate time. One such set of calls to the BatchJob instance is to return to the framework a collection of ThreadWork instances that will be distributed for execution.
• A ThreadWorker is responsible for processing a single ThreadWork instance for a run. Within the ThreadWork there are many WorkUnits representing the fine-grained units of work to be processed. In many cases the WorkUnits represent a complete database transaction, for example, a bill being created for an account. Whether or not the ThreadWorker executes on the same computer as other ThreadWorkers or the BatchJob that created its work is left as a configuration choice to be made at runtime. Within a single process, there may be many ThreadWorker objects. In general, each ThreadWorker instantiated in a batch run has a corresponding row in the Batch Instance table. The Batch Instance rows provide persistent state that is needed for the ThreadWorkers to operate correctly in failure/restart situations.