Locking basics: if a lock is placed by an explicit command, is it considered an implicit lock?

Introduction / Context:
Database systems use locks to coordinate concurrent access. Two common terms are “implicit” (locks the DBMS sets automatically) and “explicit” (locks issued directly by a user or application command). This question checks whether you can correctly classify locks set by commands.

Given Data / Assumptions:

• DBMS often acquires locks implicitly to enforce isolation during DML.
• Users/applications can request locks with explicit statements (e.g., LOCK TABLE, SELECT … FOR UPDATE).
• Terminology is standard across many SQL platforms.

Concept / Approach:
Locks placed by command are, by definition, explicit. Implicit locks are created automatically by the DBMS as part of transaction processing without a specific LOCK statement from the user.

Step-by-Step Solution:
Classify the action: a user or app issues a lock statement → explicit lock.Contrast with implicit: DBMS sets locks as needed when executing DML under isolation.Evaluate the claim: calling explicit commands “implicit locks” is incorrect.Therefore, the statement is invalid.

Verification / Alternative check:
Check DBMS manuals: explicit examples include LOCK TABLE, sp_getapplock, or SELECT FOR UPDATE; implicit examples occur during INSERT/UPDATE/DELETE under isolation.

Why Other Options Are Wrong:
Isolation level, row scope, or concurrency model does not change the definition of explicit vs. implicit.

Common Pitfalls:
Assuming all locks are implicit; overlooking that explicit locks can override defaults and escalate scope.

Final Answer:
Invalid statement