A consumer’s `isolation.level` determines whether it can read uncommitted transactional records. Set it to `read_committed` so the consumer processes only completed transactions; otherwise, reading uncommitted messages can undermine the purpose of transactions. A practical recommendation is to use `read_committed` for all consumers, even before transactions are in use. section 5.2.3 section 5.4
With `read_committed`, the broker sends records only up to the start of an unfinished transaction and holds back later records, including unrelated ones, to preserve ordering. A commit releases the held records; an abort hides records from that transaction while unrelated records remain readable. section 5.2.3 section 5.2.3
Coordinating a booking
Booking a hotel and flight together illustrates the need for a transaction: reserve the hotel, then confirm it if the flight succeeds or cancel the reservation if it fails. Kafka similarly marks written messages as tentative, then commits or aborts the transaction. section 5.2.3 section 5.2.3
Figure 5.7 Our consumer stops receiving new messages as soon as a transaction remains unfinished because the broker only sends messages up to the start of the unfinished transaction and holds back all subsequent messages, even those unrelated to the transaction. The ordering guarantee still holds. When a transaction-commit is received, all messages are released and sent to our consumer. If a transaction is aborted, our consumer doesn’t receive messages belonging to the aborted transaction, but messages not belonging to the transaction are still received normally.
Trace how an unfinished transaction holds back later records, and how committing or aborting it changes what a `read_committed` consumer receives. section 5.2.3
