Page History

...

1. Officially support functionality that can be used (and is used by Flink) anyway via reflection.
2. Relax / remove Remove the timeout for transactions participating in 2PC.

...

If the transaction is a participant of the 2PC protocol, we don’t limit the transactional timeout by the transaction.max.timeout.ms any more, so if the client passes max integer value, the broker can accept itthe transaction is never aborted automatically.

The admin client would support a new method to abort a transaction with a given transactional id.  The method would just execute InitProducerId.

...

Note that KeepPreparedTxn could be set to true even if Enable2Pc is false.  . 

Note that TransactionTimeoutMs value is ignored if Enable2Pc is specified.

Persisted Data Format Changes

...

transaction.two.phase.commit.enable The default would be ‘false’.  If set to ‘true’, then the broker is informed that the client is participating in two phase commit protocol and can set transaction timeout to values that exceed transaction.max.timeout.ms setting on the broker (if the timeout is not set explicitly on the client and the two phase commit is set to ‘true’ then the transaction never expires)transactions that this client starts never expire.

transaction.timeout.ms The semantics is not changed, but it can would be set to values that exceed an error to set transaction.max.timeout.ms if when two.phase.commit.enable is set to ‘true’'true’.

Broker Configuration Changes

...

Now if either of those commit the transaction, it would have a mix of messages from 2 instances.  With the proper epoch bump, instance1 would get fenced at step 3.

Allow Specifying Client Timeout Even When Enable2Pc=true

Technically, we could still let the client control transaction timeout that could exceed transaction.max.timeout.ms but it seems to be more confusing than useful.