Search Results submit_kill_session

Overview

FND_CONC_RAC_UTILS is an Oracle E-Business Suite PL/SQL package owned by the APPS schema that provides utility routines for managing concurrent processing sessions in an Oracle Real Application Clusters (RAC) environment. The package is declared with AUTHID CURRENT_USER and was introduced under the AFCPRACS.pls source file header (version 120.2, dated January 2008). Its stated purpose is to supply "Utilities for RAC," and its central design concern is the fact that concurrent managers and their worker sessions may execute on any node within a RAC cluster. Because a session can only be terminated directly by an instance that can see it, the package abstracts the complexity of locating and cancelling a session that may be running on a different instance than the caller. This makes the package an internal infrastructure component used by Oracle's concurrent processing framework rather than an end-user API. It is relevant to administrators and technical consultants investigating session termination behavior, orphaned concurrent requests, or hung concurrent managers in clustered EBS deployments.

Key Procedures and Functions

• KILL_SESSION — Invoked by DBMS_JOB to terminate a session identified by its session ID (sid) and serial number. This is the low-level worker routine that actually issues the session kill.
• SUBMIT_KILL_SESSION — Calls DBMS_SCHEDULER to submit a job that kills a session on a specified instance. It accepts the session identifier, serial number, and target instance, returning a status indicator (such as success, Oracle error, or inability to submit the job on the given instance) along with a message. A documented caution states that this procedure performs a COMMIT.
• SUBMIT_MANAGER_KILL_SESSION — Wraps SUBMIT_KILL_SESSION, deriving the target session from the concurrent_process_id of a concurrent manager. It reports status indicating success, session not found, or a general Oracle error.
• SUBMIT_REQ_MGR_KILL_SESSION — A convenience routine that identifies the manager associated with a concurrent request and submits a kill for that manager's session.
• SUBMIT_REQ_KILL_SESSION — A convenience routine that submits a kill for the session executing a specific concurrent request, allowing administrators to terminate a runaway request at the database session level.

The higher-level routines systematically resolve an administrator-supplied identifier (request or process ID) into a concrete sid/serial# pair and then delegate to the DBMS_JOB/DBMS_SCHEDULER mechanism for cross-instance execution.

Tables Accessed

The package reads from and writes to several core concurrent processing and security tables, using APPS synonyms. FND_CONCURRENT_REQUESTS and FND_CONCURRENT_PROCESSES are queried to map concurrent request IDs and concurrent process IDs to their executing database sessions and host instances. FND_USER, FND_RESPONSIBILITY, and FND_APPLICATION are referenced to resolve ownership and responsibility context, which is necessary to determine authorization and the correct application context for the request. The package also draws on the data dictionary and dynamic performance views GV$SESSION and V$INSTANCE to identify session and instance information across the cluster, and it interfaces with DBMS_JOB and DBMS_SCHEDULER to enqueue and execute the actual session-termination jobs.

Usage Notes

FND_CONC_RAC_UTILS is an internal framework package, referenced by zero other documented packages, and is not intended for direct invocation by end users. It is normally called indirectly by Oracle's concurrent processing and System Administrator functions—for example, when an administrator cancels a concurrent request or a concurrent manager—and by internal job scheduling when a session must be terminated on a remote RAC instance. Because SUBMIT_KILL_SESSION issues a COMMIT, custom code should not call these routines within an open transaction where atomicity is required. Consultants troubleshooting hung concurrent managers, runaway requests, or sessions that fail to terminate should recognize that the package's success depends on DBMS_SCHEDULER jobs executing on the correct instance; failures typically surface through the numeric return codes and the associated message buffer, which callers are expected to inspect.