Examine these commands which execute successfully in the sequence shown in Sessions S1 and S2: Now, examine this statement that execute successfully in s1: S1> SELECT * FROM emp; Which is true about…

Question

Exhibit

Options

• AThe inserted row is returned because the transaction is auto committed in S2.
• BThe inserted row is not returned because the isolation level is READ COMMITTED in S2.
• CThe inserted row is not returned because the transaction still active in s2.
• DThe inserted row is returned because the isolation level is RPEATABLE READ in S1.

• A
  5% (1)
• B
  5% (1)
• C
  80% (16)
• D
  10% (2)

Explanation

Option C is correct because S2's INSERT is part of an active, uncommitted transaction - until a COMMIT is issued in S2, those changes exist only within S2's transaction scope and are invisible to all other sessions, regardless of isolation level. This is the core Isolation guarantee in ACID: uncommitted data from one transaction cannot be seen by another.

Why the distractors are wrong:

• A is wrong because the transaction in S2 was explicitly started (not auto-committed); auto-commit only applies when no explicit transaction is open.
• B is misleading - READ COMMITTED prevents dirty reads (reading another session's uncommitted data), but the reason the row is hidden here is the uncommitted state itself, not S2's isolation level; isolation level of the reader (S1) is what matters for dirty reads, not S2's.
• D is wrong because REPEATABLE READ in S1 prevents already-read rows from changing within S1's transaction - it does not cause S1 to see uncommitted data from S2; it would actually make dirty reads less likely, not more.

Memory tip: Think of an uncommitted transaction as a draft saved only in a private notebook - no one else can read it until you "publish" it with COMMIT. Isolation levels control which committed data you can see, but nothing overrides the rule that uncommitted data stays private.

No community discussion yet for this question.