A Persistence application locks entity x with a LockModeType.PESSIMISTIC_READ lock type. Which statement is true?

Question

Options

• ALockModeType.PESSIMISTIC_READ is the synonym of LockModeType.READ
• BThis operation will force serialization among transactions attempting to read the entity data.
• CThis operation will result in a TransactionRolledbackException if the lock cannot be obtained.
• DIf the application updates the entity later, and the changes are flushed to the database, the lock

• A
  4% (1)
• B
  93% (26)
• C
  4% (1)

Explanation

PESSIMISTIC_READ acquires a shared lock at the database level, preventing dirty reads and forcing other transactions to wait before modifying the locked entity - this is what makes B correct: concurrent readers are serialized against writers, ensuring consistent data visibility.

• A is wrong because LockModeType.READ (alias for OPTIMISTIC) is an optimistic locking strategy that checks a version column at commit time; PESSIMISTIC_READ is an entirely different, database-level mechanism.
• C is wrong because a failure to obtain a pessimistic lock throws a PessimisticLockException or LockTimeoutException, not a TransactionRolledbackException (that exception signals an already-rolled-back transaction).
• D is incomplete in the question, but the common trap it sets up is that a PESSIMISTIC_READ lock does get automatically upgraded to PESSIMISTIC_WRITE when the entity is modified and flushed - so it isn't a static read-only lock.

Memory tip: Map the three pessimistic modes to traffic lights - PESSIMISTIC_READ = yellow (others can still read, but writes must stop), PESSIMISTIC_WRITE = red (nobody else writes), PESSIMISTIC_FORCE_INCREMENT = red + version bump. "Pessimistic = lock now, ask questions later" vs. "Optimistic = trust, then verify at commit."

No community discussion yet for this question.