Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Enchanced Recovery and Performance in a Database-based Workflow System Using MQSeries

IP.com Disclosure Number: IPCOM000010455D
Original Publication Date: 2002-Dec-04
Included in the Prior Art Database: 2002-Dec-04
Document File: 4 page(s) / 68K

Publishing Venue

IBM

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 30% of the total text.

Page 1 of 4

  Enchanced Recovery and Performance in a Database-based Workflow System Using MQSeries

Many workflow management products use a relational DBMS (Database Management System) such as DB2 to catalog information about the state of a job in the workflow system. Such systems have (possibly) a scheduler/router program/process which serves as a traffic cop (i.e. it determines what worker needs to process the job next, depending on the state of the job), and a collection of worker programs/processes that perform discrete operations on the job. Typically these workers perform database queries to determine what jobs to work on, process the job, and then update the status of the job in the database (to reflect the outcome of their operation). When there are a number of workers simultaneously processing a series of jobs on many (possibly remote) systems, the database access can become a performance bottleneck. In fact, this scenario commonly leads to database deadlock or lock timeout conditions, since many processes need to update and query the database simultaneously. Also, in the event of a system crash, the system must use the database information (the current request status), to make assumptions about how to recover requests that were being processed in the workflow.

This disclosure attempts to alleviate most database contention and deadlock conditions, and provide enhanced error recovery by using queuing software. In this system, the Router and all other workflow system workers have persistent input queues to store the jobs they need to work on (each job consists of a set of properties enumerated in XML). The first step worker's input queue is the mechanism to submit a job to the system. The first step worker takes a job off its input queue, (possibly performs some validity checking, and then places it on the Router's Status queue. The Router removes it from the Status queue, determines what type of job it is (by reading the job's XML), and then accesses it's workflow tables (stored in the database) to determine what worker to send this job to next. The Router then places the job on the input queue of the next worker, and inserts a job record (with some initial status) in the database to reflect this state (i.e. "Routed to Worker1", etc.). This next worker (Worker2), will take this job off its input queue, perform whatever function it is supposed to perform, (possibly) alter the job's XML, and then place the job on the Router's Status queue. The Router monitors this Status queue, and will remove the job from the Status queue, update the job's status in the database (to "Worker1 Successful", etc.), determine what worker to send the job to next, place it on that worker's input queue, and update the job's status in the database to reflect this new state ("Routed to Worker2", etc.). The router continues to route jobs to the appropriate workers in the system until the jobs have been completely processed.

Note that this disclosure also includes a...