Search Results fnd_conflicts_domain_u2

Overview

APPLSYS.FND_CONFLICTS_DOMAIN is a foundational configuration table in Oracle E-Business Suite 12.1.1 and 12.2.2 that defines the conflict domains used by the Concurrent Manager. A conflict domain is a logical partition within which concurrent request incompatibilities, "run alone" restrictions, and single-thread constraints are enforced. Two programs that are flagged as incompatible cannot execute simultaneously only if they reside in the same conflict domain; requests assigned to different domains are unaffected by each other's constraints. Each row in the table represents one conflict domain and records whether a run-alone program is currently active within it, which the Concurrent Manager uses to gate further submissions.

The object is owned by APPLSYS and is registered in FND Design Data as FND.FND_CONFLICTS_DOMAIN. It resides in the APPS_TS_TX_DATA tablespace with a PCT Free of 20. Under the heuristic Data Vault classification derived from its foreign-key structure, the table is satellite-leaning: its primary key, CD_ID, is referenced by FND_CONCURRENT_REQUESTS, making it a low-cardinality reference or master entity with embedded descriptive and state attributes.

Key Information Stored

The table contains eleven documented columns. The most operationally significant are:

• CD_ID — NUMBER(15), the surrogate primary key (FND_CONFLICTS_DOMAIN_PK) and conflict domain identifier.
• CD_NAME — VARCHAR2(240), the developer-facing unique name and business-key candidate (index FND_CONFLICTS_DOMAIN_U2).
• USER_CD_NAME — VARCHAR2(240), the user-facing display name for the domain.
• RUNALONE_FLAG — VARCHAR2, indicates whether a program requiring exclusive execution is currently running in the domain.
• DYNAMIC — VARCHAR2, indicates the domain was created dynamically at runtime rather than seeded.
• DESCRIPTION — VARCHAR2(240), free-text description of the domain's purpose.
• LAST_UPDATE_DATE, LAST_UPDATED_BY, CREATION_DATE, CREATED_BY, LAST_UPDATE_LOGIN — the standard Who columns, with LAST_UPDATED_BY and CREATED_BY referencing FND_USER and LAST_UPDATE_LOGIN referencing FND_LOGINS.

Both unique indexes, FND_CONFLICTS_DOMAIN_U1 (on CD_ID) and FND_CONFLICTS_DOMAIN_U2 (on CD_NAME), are NORMAL and UNIQUE, residing in APPS_TS_TX_IDX. Because CD_ID is the primary key, the _U1 index named in the search query is effectively a redundant unique index over the same column; DBA reviews of index duplication frequently flag this pair.

Common Use Cases and Queries

Typical use cases include diagnosing why a concurrent request is waiting, auditing run-alone domains, and identifying dynamically created domains that may be candidates for cleanup. A representative query to inspect all domains is:

• SELECT CD_ID, CD_NAME, USER_CD_NAME, RUNALONE_FLAG, DYNAMIC FROM APPLSYS.FND_CONFLICTS_DOMAIN ORDER BY CD_NAME;
• To detect domains currently blocked by a run-alone program: SELECT * FROM APPLSYS.FND_CONFLICTS_DOMAIN WHERE RUNALONE_FLAG IS NOT NULL;
• To review index duplication: query DBA_INDEXES for FND_CONFLICTS_DOMAIN_U1 and compare its columns against the primary key definition.
• To correlate pending requests with their domain: join FND_CONCURRENT_REQUESTS.CD_ID to FND_CONFLICTS_DOMAIN.CD_ID.

Reporting against DYNAMIC helps administrators isolate transient domains generated by ad hoc concurrent program submissions, while the Who columns provide an audit trail of who last modified a domain definition.

Related Objects

The most significant related objects, based on documented foreign-key and dependency data, are:

• FND_CONCURRENT_REQUESTS — references this table via CD_ID, assigning each submitted request to a conflict domain.
• FND_USER — referenced by CREATED_BY and LAST_UPDATED_BY.
• FND_LOGINS — referenced by LAST_UPDATE_LOGIN.
• APPS.FND_CONFLICTS_DOMAIN — the APPS synonym through which the table is normally accessed by application code and reports.

No other database objects are documented as referencing or being referenced by this table; its integration footprint is concentrated in the concurrent processing subsystem, where it functions as the enforcement boundary for request incompatibility rules.