Transaction Mastery Interview Questions

Yes — most databases wrap every individual statement in an implicit transaction if you haven't started one explicitly (this is called "autocommit mode," covered in Chapter 06). A transaction can contain exactly one operation or hundreds; the concept doesn't require multiple statements.

A group of operations treated as one unit — either all of them succeed, or none of them do.

A bank transfer: debit one account, credit another — both must happen, or neither should.

Without a transaction boundary, a crash or concurrent access between steps can leave the system in a partially-updated, inconsistent state that no single step's own error handling can detect or fix.

Yes — a multi-step read that needs a consistent view across several queries (e.g. a financial report reading several tables) also needs a transaction, specifically for isolation guarantees (Chapter 04), even though nothing is being written.

Once a logical business operation spans more than one independently-deployed database or service — at that point you need Saga, Outbox, or 2PC (Chapters 16–18), not a bigger local transaction.

COMMIT (all changes take effect) or ROLLBACK (all changes are discarded) — never a partial outcome.

Multiple steps that must either all succeed together, or leave the system completely unchanged if any one fails.

That a transaction's operations either all take effect, or none do — no partial state is ever observable.

Typically via an undo log — the previous value of each changed row is recorded before modification, so a rollback or crash recovery can restore it.

No — atomicity only covers operations within the transactional resource (the database); external side effects like an email API call are not covered and will not be undone.

Don't call the external API inside the transaction at all — persist an event/outbox record in the same transaction (Chapter 18's Outbox Pattern) and have a separate process call the external API afterward, based on that durably-committed record.

ACID consistency means data satisfies your defined constraints; CAP consistency means every read across distributed nodes sees the latest write — different concepts that happen to share a name.

No — it emerges from atomicity plus isolation plus the constraints (foreign keys, checks) you actually define.

Yes — if you never define the constraints that encode your actual business rules, the database has nothing to enforce, and logically invalid data can still be committed.

How much of another concurrently running transaction's work is visible to you before it commits.

Read Uncommitted → Read Committed → Repeatable Read → Serializable.

PostgreSQL implements Repeatable Read using a single consistent MVCC snapshot taken at the start of the transaction — new rows committed by other transactions simply aren't visible in that snapshot, which incidentally also blocks phantoms, stronger than the standard's minimum requirement.

Default the application to Read Committed, and explicitly elevate to Repeatable Read/Serializable only for specific operations (financial reports, multi-step invariant checks) where the extra correctness is worth the concurrency cost — isolation level is a per-transaction decision, not a single glob

A dirty read sees uncommitted data; a non-repeatable read sees committed data that changed between two reads of the same row within one transaction.

Read Committed.

Repeatable Read.

Phantom reads.

That once a transaction is committed, its effects survive any later crash, including a full power loss.

Sequential log appends are much faster than in-place updates to indexed data files, and the log lets a crash mid-update be safely recovered by replaying it, rather than risking a corrupted data file.

A narrow window exists where a transaction the client was told "committed" could actually be lost on a crash before its WAL entry was truly durable — unacceptable for money-moving operations.

Every individual SQL statement is automatically committed as its own implicit transaction, unless you explicitly BEGIN one yourself.

ROLLBACK discards the entire transaction; ROLLBACK TO SAVEPOINT discards only the work done after that named savepoint, leaving earlier work in the same transaction intact and still pending commit.

No — SAVEPOINT provides partial-rollback behavior within a single transaction, but there is no independently committable inner transaction in standard SQL.

Pessimistic locking blocks other transactions immediately on read; optimistic locking allows concurrent reads and only detects a conflict at write time via a version check.

They operate on different row versions — the reader sees a consistent snapshot from when it started, while the writer creates a new version, with no shared lock to contend over.

Inconsistent lock acquisition order across different code paths; the real fix is enforcing a consistent lock order everywhere (e.g. always by ascending primary key), not just adding retry logic.

When contention on a specific resource is genuinely high and expected (flash sales, limited-inventory drops) — optimistic locking under heavy contention just produces a storm of failed, retried transactions instead of preventing the contention in the first place.

No — only on unchecked exceptions (RuntimeException) and Errors by default; checked exceptions commit unless rollbackFor is specified.

No — it's a hint for optimization (skipping dirty-checking, potentially routing to a replica), not an enforced restriction.

Because a developer using checked exceptions for validation errors (a very natural Java instinct) can silently commit partial, invalid state without any error at the database level — the bug only surfaces as corrupted data downstream.

REQUIRED — join the existing transaction if one is present, or start a new one if not.

REQUIRES_NEW is a genuinely separate database transaction on a separate connection that commits independently; NESTED is a SAVEPOINT within the same single transaction, with no independent commit.

Isolation level is fixed when the physical transaction actually begins; a method joining an already-open transaction via REQUIRED doesn't start a new physical transaction, so its isolation annotation is ignored.

If the inner (REQUIRES_NEW) transaction tries to lock a row the outer, currently-suspended transaction already holds a lock on — since they're separate physical transactions on separate connections, the inner one can genuinely block waiting on the outer, which can't proceed until the inner one (whic

Via an AOP proxy wrapping the bean — the proxy runs transaction begin/commit/rollback logic around a delegated call to the real method.

this refers to the raw object, not the Spring-managed proxy — the call bypasses the proxy's TransactionInterceptor entirely.

Split into separate beans (preferred — cleanest), self-injection, or AopContext.currentProxy() with exposeProxy enabled — splitting into separate beans is preferred because it doesn't rely on exposing proxy internals.

Code at the "end" of the method still runs before the proxy's actual commit — if the commit itself then fails, an email may have already been sent for a transaction that didn't actually persist; afterCommit() guarantees the callback only fires once the commit has genuinely succeeded.

When you need transaction boundaries at a finer granularity than a whole method, or decided conditionally at runtime — e.g. per-chunk commits in a batch loop.

It relies on thread-local storage to track the current transaction, but reactive execution can hop across threads, breaking that association.

It blocks the shared event-loop thread, potentially stalling many other concurrent requests being multiplexed on that same thread — not just the one call.

Hibernate's dirty checking compares the entity's current state against a stored snapshot at flush time and auto-generates the necessary UPDATE.

Flush synchronizes pending changes to the database via SQL; commit makes already-flushed changes permanent — flush can happen multiple times before a single commit.

There's no persistence context left tracking it for dirty checking — the change exists only in the Java object's memory, with nothing left to compare it against or flush it via.

To avoid the (sometimes surprising) performance cost of automatic pre-query flushes when you know your queries don't need to see not-yet-flushed pending changes — trading a small correctness convenience for predictable, batched flush timing.

Transient, Managed, Detached, Removed.

No — it must be explicitly configured and opted into per entity, unlike the always-on first-level cache (persistence context).

The lazy proxy needs an open persistence context to run its fetch query when first accessed — once the transaction (and persistence context) has closed, there's no session left to fetch through, so Hibernate throws rather than silently failing.

It hides real N+1 query problems by making lazy loading "just work" anywhere in the request, and blurs the transaction boundary across the entire web layer, making it harder to reason about exactly when and where database work happens.

Yes — every single-document write has always been fully atomic, regardless of how many fields or nested arrays it touches.

Multi-document transactions rely on the oplog and replication infrastructure that only exists in a replica set configuration.

Model data so related, together-changing information lives in one document to get atomicity for free; use multi-document transactions only for genuinely cross-document operations that can't reasonably be modeled otherwise.

Spring's @Transactional and PlatformTransactionManager interface are resource-agnostic — swapping DataSourceTransactionManager/JpaTransactionManager for MongoTransactionManager changes the backing implementation without changing how your service code declares its transaction boundaries.

@Transactional only controls the local database connection/transaction it's bound to — a network call to another service is entirely outside that scope and cannot be rolled back by it.

The inability to atomically commit a database write and a message publish (e.g. to Kafka) together — one can succeed while the other fails, since they're two separate systems.

A deeper constraint — a single database transaction is inherently scoped to one connection/database at the protocol level; no framework abstraction can make one COMMIT atomically span multiple independent databases.

Prepare (vote) and Commit/Abort (decide) — nothing is actually committed until every participant has voted yes.

It's stuck holding its locks indefinitely, unable to independently decide to commit or abort — this "blocking" behavior is 2PC's core structural weakness.

It requires all participants to be synchronously available throughout both phases and introduces a coordinator as a new single point of failure — both work against microservices' goals of independent availability and scaling.

When strict, immediate consistency is a hard regulatory or correctness requirement, participant count is small and tightly controlled, and the availability/scaling cost is acceptable — genuinely rare in typical high-scale web/mobile backend systems, but real in some financial core-banking contexts.

Compensating transactions — forward-moving actions that reverse the effect of an already-committed earlier step.

Choreography has no central coordinator — services react to each other's events independently; orchestration has an explicit orchestrator directing every step and deciding what happens next.

Event-driven communication (typically Kafka) commonly guarantees at-least-once delivery, so any step can be invoked more than once for the same logical event — non-idempotent steps would double-apply their effect (e.g. double-charging a card).

Place the irreversible action as the very last step in the saga, after every reversible step has already succeeded — this minimizes the window in which a failure would leave something un-compensable.

The dual-write problem — atomically recording a business change and its corresponding event, since the database and message broker can't be committed together directly.

CDC reads the database's own commit log directly, so it only ever sees truly committed changes and can resume precisely after a crash — a polling relay's separate "publish" and "mark published" steps have their own smaller dual-write gap.

Both avoid trying to make two different systems atomic with each other — instead, they make an idempotency record and the actual effect atomic within a single local database transaction.

The entire mechanism depends on Chapter 02's local atomicity guarantee — the business write and outbox write must be part of the same physical database transaction, which is only possible if they share the same database.

At-least-once — messages are never silently lost, but can be redelivered and processed more than once.

The idempotent producer (deduplicates retried sends via sequence numbers) and Kafka transactions (atomically group multiple writes, including offset commits, together).

No — it only ensures consumers don't see uncommitted/aborted transaction data (Kafka's version of preventing a dirty read); it must be paired with a transactional producer to get the full atomic guarantee.

No — that's the exact same dual-write problem from Chapter 15; Kafka transactions only cover atomicity across Kafka topics/partitions themselves, not an external system, which is why the Outbox Pattern (Chapter 18) exists as a separate solution for that boundary.

A saga (likely orchestrated by a central switch), because the two banks' ledgers are independent systems — a single cross-bank distributed transaction isn't realistic at that scale/ownership boundary; failures are handled via a compensating reversal credit.

Pessimistic locking (SELECT FOR UPDATE) on the specific inventory row under high contention, backed by a database CHECK constraint (stock >= 0) as a final safety net.

These systems need high availability and independently scalable services; 2PC's blocking coordinator model directly works against both, and eventual consistency via Saga/Outbox is an acceptable, well-handled trade-off for this domain.

A transaction that's open but not actively running a query (e.g. waiting on external I/O) — it still holds locks and an MVCC snapshot the whole time, silently degrading concurrency for other transactions.

Use a shared correlation/saga ID propagated through every event and log line, and query distributed tracing (or grep centralized logs) by that ID to reconstruct the full cross-service timeline.

Outbox table backlog size (unpublished row count) — a growing backlog is a leading indicator, visible before downstream services experience any missing-event symptoms.

Should reference Chapter 01's all-or-nothing definition and a concrete story (bank, ATM, flight).

All four letters, correctly — and specifically that Consistency (Chapter 03) is an emergent property, not a separate log/lock mechanism like the other three.

The AOP proxy mechanism (Chapter 10) — this refers to the raw object, bypassing the proxy's TransactionInterceptor.

Saga (Chapter 17), with specific compensations named for each step, and a clear explanation of why 2PC (Chapter 16) is the wrong choice at this scale/availability requirement.

Outbox Pattern with CDC (Chapter 18) — write to a local outbox table atomically with the order, relay independently.