jolshan commented on code in PR #21735:
URL: https://github.com/apache/kafka/pull/21735#discussion_r4498583285
##########
transaction-coordinator/src/main/java/org/apache/kafka/coordinator/transaction/TransactionMetadata.java:
##########
@@ -108,6 +112,27 @@ public TransactionMetadata(String transactionalId,
this.lock = new ReentrantLock();
}
+ public boolean hasNextProducerEpoch() {
+ return nextProducerEpoch != RecordBatch.NO_PRODUCER_EPOCH;
+ }
+
+ // When InitProducerId keeps an Ongoing transaction (which is "prepared"
from
+ // the 2PC protocol perspective) it needs to preserve the producerId /
epoch of
+ // the transaction (that will be used for sending markers), but update the
+ // producerId / epoch that's going to be used by client (so that we could
fence
+ // stale client requests). For backward compatibility (in case of server
+ // downgrade) we keep the producerId / epoch of the transaction in the
+ // producer* fields and the other pair in the nextProducer* fields.
+ // Note that we check hasNextProducerEpoch because nextProducerId could
Review Comment:
I think it is valid and works now, but it is a little tricky that
nextProducerEpoch is used to signify that 2pc is causing the producer id/epoch
to diverge. If someone (or AI) was just looking at the code with no context,
they could accidentally add `epoch + 1` into this field and it would have the
wrong effect. I wonder if there is anything we can do to guard against this.
The comment here is a good start.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
