conduktor.io ↗

transactional.id — Kafka Producer Configuration

The TransactionalId to use for transactional delivery. This enables reliability semantics which span multiple producer sessions since it allows the client to guarantee that transactions using the same TransactionalId have been completed prior to starting any new transactions.

Description

The TransactionalId to use for transactional delivery. This enables reliability semantics which span multiple producer sessions since it allows the client to guarantee that transactions using the same TransactionalId have been completed prior to starting any new transactions. If no TransactionalId is provided, then the producer is limited to idempotent delivery. If a TransactionalId is configured, enable.idempotence is implied. By default the TransactionId is not configured, which means transactions cannot be used. Note that, by default, transactions require a cluster of at least three brokers which is the recommended setting for production; for development you can change this, by adjusting broker setting transaction.state.log.replication.factor.

Default Values by Kafka Version

Kafka VersionDefault Value
0.11.0null
1.0null
1.1null
2.0null
2.1null
2.2null
2.3null
2.4null
2.5null
2.6null
2.7null
2.8null
3.0null
3.1null
3.2null
3.3null
3.4null
3.5null
3.6null
3.7null
3.8null
3.9null
4.0null
4.1null
4.2null

Tuning Recommendation

ProfileRecommendedWhy
producer / durability"<app-name>-<instance-id>"Setting a stable transactional.id enables the transactional API (beginTransaction/commitTransaction/abortTransaction), which provides atomic writes across multiple partitions and topics; consumers with isolation.level=read_committed see only committed records. The ID must be unique per producer instance and stable across restarts to allow epoch fencing of zombie producers.

Related Configs

enable.idempotence · acks · transaction.timeout.ms

Manage Kafka configs across all your clusters with Conduktor Console — view, compare, and update configurations in one place.