Если транзакция не завершилась, и сервис упал, то метаданные транзакции останутся висеть в незавершенном состоянии в топике __transaction_state. Если таких транзакций будет много - может в итоге выстрелить и по производительность, и по размеру файла-топика на диске;
При перезапуске сервиса, у него будет новый transaction.id, и старые незавершенные транзакции останутся навсегда незавершенными. Если бы стартанули с предыдущим transaction.id - они бы завершились;
Если у консумера уровень изоляции установлен на read_committed, то он может подвиснуть на таких незавершенных транзакциях.
Это из того, что вспомнил.
Поэтому для каждой инстанции сервиса корректнее использовать уникальный, но жестко заданный transaction.id
Часто сталкиваюсь с подобным поведением таксистов - им принудительно назначается заказ, или они не отказываются от заказа из-за "штрафов", но выполнять заказ не хотят, и поэтому стоят на месте. Раньше я пытался звонить, или писать - и там получаю в ответ, чтобы я отменял заказ.
Но с какого-то момента в приложении появилась функция вызвать еще одну машину, что позволяет прекрасно "работать" с подобными персонажами - вызываю еще одну машину, и еду уже на ней, а этот первый водитель продолжает стоять на месте. Спустя какое-то время первый водитель начинает показывать что он не приедет - уезжает в противоположном направлении за пару километров, и там включает режим ожидания, что он на месте, соответственно начинают еще насчитываться деньги за ожидание. Я все эти маневры скриншотю, чтобы приложить в переписку со службой поддержки. Спустя какое-то время, первый заказ отменяется, и я пишу в службу поддержки Яндекса, с описанием всей этой картины, прикладывая скриншоты, и с просьбой больше не назначать этого водителя на мои заказы. И всегда в подобной ситуации Яндекс на моей стороне, списанные деньги возвращают - так что к Яндексу вообще никаких претензий.
Привет! Спасибо за цикл статей!
Но совет, что надо каждый раз использовать рандомный transaction.id (spring.kafka.producer.properties.transactional.id=some-service-${random.value}-) - имеет определенный набор проблем:Если транзакция не завершилась, и сервис упал, то метаданные транзакции останутся висеть в незавершенном состоянии в топике
__transaction_state. Если таких транзакций будет много - может в итоге выстрелить и по производительность, и по размеру файла-топика на диске;При перезапуске сервиса, у него будет новый
transaction.id, и старые незавершенные транзакции останутся навсегда незавершенными. Если бы стартанули с предыдущим transaction.id - они бы завершились;Если у консумера уровень изоляции установлен на read_committed, то он может подвиснуть на таких незавершенных транзакциях.Это из того, что вспомнил.
Поэтому для каждой инстанции сервиса корректнее использовать уникальный, но жестко заданный transaction.id
Часто сталкиваюсь с подобным поведением таксистов - им принудительно назначается заказ, или они не отказываются от заказа из-за "штрафов", но выполнять заказ не хотят, и поэтому стоят на месте. Раньше я пытался звонить, или писать - и там получаю в ответ, чтобы я отменял заказ.
Но с какого-то момента в приложении появилась функция вызвать еще одну машину, что позволяет прекрасно "работать" с подобными персонажами - вызываю еще одну машину, и еду уже на ней, а этот первый водитель продолжает стоять на месте. Спустя какое-то время первый водитель начинает показывать что он не приедет - уезжает в противоположном направлении за пару километров, и там включает режим ожидания, что он на месте, соответственно начинают еще насчитываться деньги за ожидание. Я все эти маневры скриншотю, чтобы приложить в переписку со службой поддержки. Спустя какое-то время, первый заказ отменяется, и я пишу в службу поддержки Яндекса, с описанием всей этой картины, прикладывая скриншоты, и с просьбой больше не назначать этого водителя на мои заказы. И всегда в подобной ситуации Яндекс на моей стороне, списанные деньги возвращают - так что к Яндексу вообще никаких претензий.