Search Results argument_text




Overview
Explore in AI Chat

Overview

FND_CONC_WAITING_REQUESTS is a read-only view owned by the APPS schema in the Oracle E-Business Suite Application Object Library (FND). It exposes the set of concurrent requests that are currently pending execution and, for each, identifies the running request that is blocking it. In effect, the view answers two related questions: which requests are waiting, and why they cannot yet start. This makes it a diagnostic instrument for the Concurrent Manager subsystem rather than a transactional object; it holds no data of its own and is populated entirely at query time from the concurrent request tables and supporting logic.

Because the view is defined in terms of live status codes and scheduling attributes, its contents change continuously as the concurrent managers dispatch work. It is intended for administrative monitoring, capacity analysis, and custom reporting where an administrator needs visibility into queue contention. The view exists in both 12.1.1 and 12.2.2 with the same documented structure; the underlying base objects are consistent across those releases.

Underlying Base Objects

ETRM documents the following referenced base objects: the package FND_AMP_PRIVATE, the view FND_AMP_REQUESTS_V, and the synonyms FND_CONCURRENT_PROGRAM_SERIAL and FND_CONCURRENT_REQUESTS, together with the view FND_CONCURRENT_WORKER_REQUESTS.

  • FND_CONCURRENT_REQUESTS — the primary request table; the view aliases it as R1 to represent the running request whose resource constraints block others.
  • FND_AMP_REQUESTS_V — a request view aliased as R2, supplying the waiting candidates and their scheduling attributes (priority, phase, hold and enabled flags, run-alone flag, queue method, request limit, single-thread flag, and requested start date).
  • FND_CONCURRENT_WORKER_REQUESTS — used in a subquery to determine which requests have active worker processes and are therefore eligible to run.
  • FND_CONCURRENT_PROGRAM_SERIAL — referenced for program serialization constraints.
  • FND_AMP_PRIVATE — a package supplying the PL/SQL functions GET_PHASE, GET_STATUS, and WHY_WAIT, which derive the human-readable PHASE, STATUS, and WHY columns.

Key Columns

  • REQID — the request identifier of the running (blocking) request, from R1.
  • WREQID — the request identifier of the waiting request, from R2.
  • PROGRAM — the concurrent program short name of the waiting request.
  • USER_NAME — the user associated with the waiting request.
  • PHASE and STATUS — derived values returned by FND_AMP_PRIVATE.GET_PHASE and GET_STATUS, reflecting the request's current processing state.
  • WHY — the output of FND_AMP_PRIVATE.WHY_WAIT, describing the incompatibility rule preventing execution (for example, run-alone, single-thread, request-limit, or program serialization conflicts).
  • ARGUMENT_TEXT — the concatenated parameter values passed to the waiting program.
  • PRIORITY — the scheduling priority of the waiting request.

Note that the search term requested_by is not projected as a column. REQUESTED_BY appears only within the view's filter and join predicates, where it enforces single-thread and request-limit matching between the running and waiting requests belonging to the same user.

Common Use Cases and Queries

Administrators use this view to investigate why submitted requests remain in a pending state, to identify the dominant blocking requests in a contention scenario, and to monitor queue throughput.

  • List all waiting requests and their blocking reasons:
    SELECT wrepid, program, user_name, phase, status, why, priority FROM fnd_conc_waiting_requests ORDER BY priority;
  • Find requests blocked by a specific running request:
    SELECT wrepid, program, user_name, why FROM fnd_conc_waiting_requests WHERE reqid = :request_id;
  • Count waiters per blocking request to locate serialization bottlenecks:
    SELECT reqid, COUNT(*) FROM fnd_conc_waiting_requests GROUP BY reqid ORDER BY 2 DESC;

Because the view performs no persistence and invokes functions within FND_AMP_PRIVATE, queries should be limited in scope, particularly in heavily loaded environments.