The Life of a Concurrent Request

---

The life cycle of a concurrent request starts when the request is made and ends when the request is finished. Finished can mean successful completion or complete failure or statuses in between.

The user submits a request for a concurrent job. This job can be a report, a SQL*Loader job to bring data from the outside into an interface table, or any other Concurrent Program. When the request is submitted, an entry record is placed into the FND_CONCURRENT_REQUESTS table identifying the request as being available and specifying what its schedule is, if it is not to be run as soon as the request is submitted.

The next time the relevant manager wakes up and poles the FND_CONCURRENT_REQUESTS table, it will find the entry and determine if it is incompatible with any other running request currently on the system. If it is incompatible, the request gets passed to the CRM for processing. If there are no incompatibilities, the request gets put into its relevant queue (the Standard Manager queue if no other manager is specified for that request). The manager that is assigned to process that request checks to see if it has any available processes. If any are available, the request gets processed; if none are available, the request goes back into the queue to attempt to be processed in the next cycle.

When the request is being processed, an entry in the FND_CONCURRENT_REQUESTS table gets updated with the status information of that particular request.

A concurrent request can have many phases (i.e., pending, running, completed, and inactive) and each phase can have several different statuses. Table 12.2 gives you a description of each phase/status combination. Figure 12.1 shows you, graphically, what having several requests of varying statuses will look like in the concurrent requests window.

Table 12.2: Concurrent Manager Phase/Status Combination

Phase	Status	Description
Pending	Normal	The request is awaiting the next available manager.
	Standby	The request is awaiting the next available manager, but is incompatible with other Concurrent Programs currently running.
	Scheduled	The request is scheduled to run at some future time. These schedules can be a single report scheduled to run once in the future or can be a report that is scheduled periodically.
	Waiting	The request is a spawned child request awaiting its parent request to complete to a point where it can be marked as ready to run. This often happens when one program has to wait for another program to finish so the child can use the output of the parent.
Running	Normal	Request is currently running.
	Paused	Request is paused waiting for other requests in its set to finish. This typically happens when a parent request finishes its initial processing, but cannot officially finish until all of its child processes are done.
	Resuming	Once all child requests that have been submitted by a parent request have completed (those causing the paused status described above), the parent status will become resuming.
	Terminating	If the user or the sysadmin chooses to terminate the request from the Request Details screen, the status of the request goes to terminating.
Completed	Normal	The request completed normally.
	Error	The request failed to complete successfully. Details can be retrieved from the requests log file.
	Warning	Request completed, but completed with warnings. Often these warnings are due to a failure of a successfully generated report to print.
	Cancelled	The request was cancelled while its status was still pending or inactive.
	Terminated	Request was running when it was terminated (see Running Terminated above).
Inactive	Disabled	This is indicative of a program that has been requested, but the program has not been enabled. If a request has this status, the sysadmin will be the one called.
	On Hold	A pending request that has been placed temporarily on hold.
	No Manager	There are either no managers defined for the given request or there is a problem with the Concurrent Managers. Requests often have this status after patching or cloning when there is either something wrong with the Concurrent Managers or they have been deactivated.

Figure 12.1: Concurrent Requests with Varying Statuses

---