Pull to refresh
4
0
Send message

Использую ParallelScheduler. PARALLELISM - 10

А здесь уже возникает опять вопрос STP. Так как из «деньги списаны» в «запрос в доставке» переход должен проходить автоматически, т.е. сервис после восстановления работы должен сам решать такие кейсы, но есть много примеров, в которых не имеет смыслка декомпозиция иначе получится «Запрос на резервирование получен» -> «Запрос на резервирование доставлен в обработчик» -> «Запрос на резервирование в обработке» -> «Запрос на резервирование обработан» -> «Товар зарезервирован». И эти степы никакого отношения к бизнес процессу иметь не будут
Ок. Вопрос про STP остаётся актуален. По первому вопросу пример такой. Допустим машина получила RESERVED, записала в БД состояние, после клиент кинул BUY, машина его получила, прошёл платёж, а дальше сервис упал. После восстановления будем иметь неконсистентный заказ. Если клиент ещё раз кинет BUY, то деньги спишутся ещё раз, но и служба доставки его не получила. Как всё таки допинать до терминального статуса такой кейс?
Добрый день! Спасибо за статью. У меня продолжение для предыдущего вопроса. Если машина была остановлена когда уже получила новый евент, но ещё не успела обработать его можно ли как-то зареплаить этот евент при восстановлении чтобы не перепосылать (тут вопрос наверно про транзакционность и DR)? И есть ли возможность каких-то STP. Например для мы кинули евент RESERVED, а машина дальше допинала через BUY по определённому условию?
К сожалению нет. И это наглядно видно иначе бы объёмы условных 100 килограммовых толстяков не отличались бы от объёмов 100 килограммовых качков
Видимо Вы так и не поняли. С коэффициентом я ошибся. Он равен 4. Попытаюсь доступным языком. 1кг мышц занимает в 4 раза меньший объём чем 1кг жира.
Сорри, не смог дочитать статью. Показалось что вы решили обойти научную литературу и всю известную информацию касательно процессов в организме. Измерять кол-во подкожного жира по весу, это всё равно что измерять мощность машины по объёму двигателя. Зависимость есть, но она непропорциональная. Если учитывать что в плохом случае в вашем организме 30% жира, то при похудении вы теряете не только жир, а так же что-то из остальных 70%. Более правильным было бы измерять объёмы организма. Если вы посмотрите вокруг, то увидите что много людей в схожих комплекциях (читай объёмах), но с разными весами. Всё от того, что мышцы весят примерно в 7 раз больше жира. А в целом для простого похудения моделей не нужно, так как в процесее построения этой самой модели уже будет обнаружена равновесная каллорийность организма, от которой и нужно шагать. Достаточно просто сокращать каллорийность рациона и следить за результатами. Опять же похудение не должно иметь экстримальным. Когда вы теряете за неделю 2кг веса (не воды из огранизма за счёт отёков), это скорее всего говорит о том что, что-то идёт неправильно и вы недополучаете нужных организму веществ.

P.S. По поводу питья воды во время еды. Пить воду можно. Желудок имеет две кривизны и вода идёт не по той, что и твёрдая пища (что логично). Но это касается только чистой воды. Соки, газировки и чаи не входят.
Имеем следующую структуру
Stream<T> extends BaseStream<T, Stream<T>> 

BaseStream<T, S extends BaseStream<T, S>> {
    S parallel();
    S sequential();
}

В результате если бы Stream не расширял бы BaseStream от себя, то методы
S parallel();
S sequential();
возвращали бы просто BaseStream, в котором нет методов интерфейса Stream. Поэтому, чтобы пользоваться методами предка, как если бы они были методами самого интерфейса есть вот такой подход. Его обычно называют рекурсивные дженерики
Ещё нетривиальный пример со стримами где интерфейс Stream расширяет BaseStream<T, Stream>

Information

Rating
Does not participate
Registered
Activity

Specialization

Backend Developer, Software Architect
Lead
Java
Java Spring Framework
High-loaded systems
Parallel programming