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:
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.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, these
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.