Concurrency Control — What Can a Shared Lock Do? In transactional database systems, a shared lock (S-lock) permits which activity while protecting data from conflicting modifications?

Introduction / Context:
Locks are fundamental to concurrency control. A shared lock allows concurrent readers while preventing writers from altering the locked resource. Understanding this distinction helps prevent anomalies like dirty reads and lost updates in multi-user environments.

Given Data / Assumptions:

• A shared (S) lock is being considered.
• We assume a standard two-phase locking model with shared/exclusive compatibility rules.
• Goal: determine which operation is permitted under a shared lock.

Concept / Approach:
Shared locks are compatible with other shared locks, enabling multiple transactions to read the same data concurrently. However, they conflict with exclusive (X) locks, which are needed for modifications. Thus, reading is allowed; inserting, updating, or deleting the locked row/page requires exclusive intent.

Step-by-Step Solution:
Identify permitted operations under S-lock: non-destructive reads.Recognize forbidden operations: modifications that need X-locks (update, delete) or schema changes.Map “read” to the allowed, concurrent operation under shared locks.Select “Read.”

Verification / Alternative check:
Lock compatibility matrices show S is compatible with S, but S is incompatible with X. Reads use S locks; writes request X locks (or intent locks leading to X at finer granularity).

Why Other Options Are Wrong:

• Delete/Update/Insert require exclusive or intent-exclusive locks to modify data.
• Drop table is a DDL operation not permitted under S-lock on rows/pages; it typically requires stronger metadata locks.

Common Pitfalls:
Assuming inserts are always compatible with shared locks; while inserts may coexist via intent locks, they do not use a shared lock on the same target row.

Final Answer:
Read