Спасибо за ответ. Идея понятна в принципе. Нр справедливости ради хотелось бы отметить, что retry policy можно настроить и на целевые события, и обойтись без компенсирующих.
Ибо если затык на уровне БД происходит, к примеру из-за таймаутов, допустим в том же методе бронирования, то отмена бронирования будет в 99% случаев обращаться, к примеру, к той же заблокированной таблице (по неизвестным нам причинам).
Только в случае компенсации, у нас позже сработает повторная отмена брони, и пользователю придется вновь проходить весь этап. А в случае без компенсационного метода, мы просто позже проведем попытку бронирования повторно.
Но здесь все сугубо ситуационно. Поэтому конечно для каждой ситуации, требуется предварительный анализ, с решением какой вариант подойдет больше
Это хорошая статья на мой взгляд. Но у меня возникает вопрос. А что если исключение происходит в компенсирующем событии? Здесь нужно компенсирующее событие для компенсирующего события? Или как это работает?
Спасибо за ответ. Идея понятна в принципе. Нр справедливости ради хотелось бы отметить, что retry policy можно настроить и на целевые события, и обойтись без компенсирующих.
Ибо если затык на уровне БД происходит, к примеру из-за таймаутов, допустим в том же методе бронирования, то отмена бронирования будет в 99% случаев обращаться, к примеру, к той же заблокированной таблице (по неизвестным нам причинам).
Только в случае компенсации, у нас позже сработает повторная отмена брони, и пользователю придется вновь проходить весь этап. А в случае без компенсационного метода, мы просто позже проведем попытку бронирования повторно.
Но здесь все сугубо ситуационно. Поэтому конечно для каждой ситуации, требуется предварительный анализ, с решением какой вариант подойдет больше
Это хорошая статья на мой взгляд. Но у меня возникает вопрос. А что если исключение происходит в компенсирующем событии? Здесь нужно компенсирующее событие для компенсирующего события? Или как это работает?
где в кроссворде 38Г, не могу найти? 38В вижу