Examine these statements issued from Session 1 which execute successfully: Now, examine these statements issued from Session 2 which execute successfully: Session 2> BEGIN; UPDATE band SET…

Question

Options

• ASession 1 takes a shared lock on all the rows in the band table.
• BSession 1 must commit before the update in Session 2 can complete.
• CSession 1 does not block Session 2.
• DStatements in Session 2 are committed.
• ESession 2 takes an exclusive lock on all the rows in the band table.
• FSession 2 does not start a transaction.

• A
  16% (10)
• B
  67% (41)
• C
  8% (5)
• E
  5% (3)
• F
  3% (2)

Explanation

B is correct because Session 1's DML (likely an UPDATE or similar write operation) acquires exclusive row-level locks on the affected rows in the band table. Since Session 2's UPDATE targets overlapping rows, it is blocked and cannot complete until Session 1 issues a COMMIT or ROLLBACK. D is correct because the question explicitly states Session 2's statements "execute successfully," confirming the transaction ultimately completed and was committed (once Session 1 released its lock).

Why the distractors are wrong:

• A is wrong - DML statements take exclusive locks, not shared locks; shared locks are associated with certain read operations like SELECT ... FOR SHARE.
• C is wrong - Session 1 absolutely does block Session 2, since both target the same rows and exclusive locks prevent concurrent writes.
• E is wrong - Session 2's UPDATE uses a WHERE clause (LIKE '%Sun'), so it locks only the matching rows, not all rows in the table.
• F is wrong - Session 2 explicitly issues BEGIN, which unambiguously starts a transaction.

Memory tip: Think of it as a "one writer at a time" rule - a DML lock is like a bathroom key: Session 1 has it, so Session 2 must wait at the door until Session 1 commits and hands the key back. Row-level, not table-level (unless specified).

No community discussion yet for this question.