Locking semantics and control Locks that are explicitly requested by an application or a specific SQL statement (rather than acquired implicitly by the engine) are called:

Introduction / Context:
Database engines automatically take many locks implicitly to enforce isolation. Sometimes, applications or DBAs request locks directly to control access patterns or prevent specific anomalies. These are known by a standard term.

Given Data / Assumptions:

• We distinguish between the engine's automatic behavior and application-invoked locking.
• Examples include explicit table locks or SELECT ... FOR UPDATE.

Concept / Approach:

When an application or statement requests a lock via syntax or procedure, the lock is explicit. By contrast, implicit locks are acquired automatically by the optimizer/executor to satisfy isolation guarantees without programmer intervention.

Step-by-Step Solution:

Verification / Alternative check:

DBMS references categorize locks by acquisition method (implicit vs. explicit) and by mode (shared, exclusive, update). The question asks the method, not the mode, matching “explicit.”

Why Other Options Are Wrong:

• Implicit locks: acquired automatically by the engine, not by command.
• Exclusive locks: a mode that prevents others from writing, orthogonal to explicitness.
• Shared locks: another mode, allowing concurrent readers.
• Update locks: a specialized mode for conversion patterns, not acquisition method.

Common Pitfalls:

• Confusing “how” a lock is taken (explicit/implicit) with “what” the lock does (mode).
• Using broad exclusive locks instead of precise row/page locks, causing contention.

Final Answer:

Explicit locks.