Search Results cd_id




Overview
Explore in AI Chat

Overview

APPS.FND_CONC_WAITING_REQUESTS is a diagnostic and reporting view within the Oracle E-Business Suite Concurrent Processing subsystem. Its purpose is to expose, for any given running or active concurrent request, the set of other pending requests that are waiting on it and the reason they are blocked. Rather than reporting on a single request in isolation, the view performs a correlated self-join between FND_CONCURRENT_REQUESTS (aliased R1, representing the currently executing request) and FND_AMP_REQUESTS_V (aliased R2, representing a candidate waiting request), evaluating compatibility through the FND_AMP_PRIVATE package.

The view is therefore a companion to runtime diagnosis of the concurrent manager. It answers the practical question of why a request has not yet started: which conflicting request holds it up, and on what grounds (priority, single-thread flag, run-alone flag, request limit, serialization, or sub-request dependency). In EBS 12.1.1 and 12.2.2, the view remains relevant because the underlying concurrency model and the FND_AMP_PRIVATE compatibility logic are unchanged between those releases.

The mention of run_alone_flag in the view text reflects a key blocking condition: a pending request with RUN_ALONE_FLAG = 'Y' conflicts with a running request when they share the same conflict domain (cd_id). This is one of the exclusion rules evaluated in the WHERE clause.

Underlying Base Objects

The view is defined over two primary sources joined in the FROM clause, supplemented by package calls and a subquery. Its referenced base objects (per ETRM 12.2.2) are:

  • FND_CONCURRENT_REQUESTS (synonym; R1) — supplies the running request's identity, priority, status, single-thread flag, request limit, program identifiers, and conflict domain.
  • FND_AMP_REQUESTS_V (view; R2) — the pending request side, supplying priority, requested start date, queue method, run-alone flag, single-thread flag, request limit, sub-request indicators, and parent request.
  • FND_AMP_PRIVATE (package) — provides GET_PHASE, GET_STATUS, and WHY_WAIT. WHY_WAIT computes the textual explanation of the blocking condition; GET_PHASE and GET_STATUS derive the human-readable phase and status of the waiting request.
  • FND_CONCURRENT_PROGRAM_SERIAL (synonym) — used in an existence subquery to detect program-serialization conflicts between the running and waiting programs.
  • FND_CONCURRENT_WORKER_REQUESTS (view) — used in a subquery to identify requests assigned to worker queues with active running processes.

Key Columns

  • reqid — REQUEST_ID of the running (blocking) request R1.
  • wreqid — REQUEST_ID of the waiting request R2.
  • program — Concurrent program short name of the waiting request.
  • user_name — Requesting user of the waiting request.
  • phase / status — Derived via FND_AMP_PRIVATE.GET_PHASE and GET_STATUS, giving readable processing state of the waiting request.
  • argument_text — Parameters of the waiting request.
  • priority — Scheduling priority of the waiting request.
  • why — The output of FND_AMP_PRIVATE.WHY_WAIT, explaining the blocking cause; this is the column most often consumed in reports.
  • run_alone_flag (R2) — When 'Y', the pending request must run exclusively within its conflict domain.

Common Use Cases and Queries

Administrators and support teams use this view when investigating a stalled concurrent queue, to identify exactly which running request is holding up a pending one and through which mechanism. A typical query lists all waiting requests and their blocking explanation:

  • SELECT reqid, wreqid, program, user_name, phase, status, why FROM apps.fnd_conc_waiting_requests ORDER BY priority, wreqid;
  • To isolate run-alone induced blocking: SELECT * FROM apps.fnd_conc_waiting_requests WHERE why LIKE '%alone%';
  • To trace a specific blocked request: SELECT * FROM apps.fnd_conc_waiting_requests WHERE wreqid = :request_id;

Because the view evaluates live status codes and compatibility at query time, results reflect the present state of the concurrent manager rather than a persisted history.