Two independent Lakeflow Jobs write to the same Delta table at the same moment. One appends a batch of new rows while the other deletes rows matching a predicate on an unrelated set of dates. Neither job takes an explicit lock. Which statement describes how Delta Lake handles this?
- AThe second writer waits on a table-level lock held by the first writer, and its own commit proceeds only once the first writer has finished its transaction.
- BDelta Lake applies optimistic concurrency control, so each writer reads a snapshot, then commits, and retries or fails only when the files the two transactions touch overlap. Correct
- CBoth commits are accepted unconditionally, because Delta Lake reconciles the two sets of changes at the file level during the next OPTIMIZE run on the table.
- DThe table is left in an intermediate state until a later reader repairs the transaction log by comparing the committed entries against the files in storage.
Why A is wrong: This describes pessimistic locking, which is a reasonable expectation from relational systems, but Delta Lake does not block writers up front and instead resolves conflicts at commit time.
Why B is correct: Correct, because writers proceed without blocking and the commit protocol checks for conflicting file changes, which lets disjoint writes such as these two succeed together.
Why C is wrong: OPTIMIZE compacts small files and does not merge competing transactions, so treating it as a conflict resolver would allow a lost update between the moment of the commit and the moment of compaction.
Why D is wrong: Readers never repair the log, and a commit is atomic, so no intermediate state is ever visible; this confuses Delta Lake with systems that need a recovery pass after a crash.