daminik00, да
тебе важно понять, что транзакция это блок, в котором будет выполнено или "всё успешно" или "всё откатили"
то есть если ты внутри транзакции изменил один документ, второй, пятый и так далее, но потом сделал abortTransaction по какой-то причине (условие баланса не подошло), то все документы откатятся, очень грубо говоря транзакции выполняются друг за другом (но это немного не так, читать про causal consistency)
daminik00, нет, я же пишу, что транзакционно, как они одновременно начнут?
10 запросов на начало прилетает на сервер, транзакционно: транзакция началась
1) выбрали задание
2) выбрали исполнителя
3) списали деньги если есть на счету
4) зачислили на вирт счет транзакция закончилась
таким образом транзакция выполнится успешно только для одного исполнителя, для других она упадет на шаге 3
сделать 2 фазы у задания: начать выполнение, закончить выполнение
на фазе 1 - "начать выполнение" деньги замораживаются и списываются на виртуальный счет, это происходит транзакционно, таким образом начать сможет только один из исполнителей, остальные получат ошибку, что задание уже в процессе
на фазе 2 - "закончить выполнение" деньги или переходит исполнителю или отзываются
в случае провала задания или таймаута
названия фаз можно поменять: "начать просмотр задания", "выполнить задание". Сути это не меняет
а как транзакционно делается запись в БД и взаимодействие с 3ми АПИ (например апи платежек)? интересует кейс, когда где-то что-то зафейлилось как это откатить?
а что если при открытии каждого файла возвращать канал, в который пишутся операции над файлом, в которые этот файл прокидывается?
операции исполняются одна за другой синхронно
Губернатор, проблема в том, что это кажется только тебе. Покорение высот происходит командами. В большинстве своем этот язык неудобен: плохой пример ООП, легкость выстрелить себе в ногу. Он проверен временем и занял свою нишу. Для веба много других удобных и шустрых инструментов
Сергей, с RPC пока не укладывается в голове как реализовать, сервер не хранит ответ (а только состояние игрока и комнаты).
Это игра: клиент сделал запрос, {списалась сумма, посчиталось текущее текущее состояние и сгенерировался ответ}(транзакционно), отправилось игровое состояние.
Если уходить в RPC, то придётся и на сервере реализовывать логику повторного запроса (но без списания суммы, иначе двойная ставка спишется) и клиент меня. По этой причине (как одной из) несколько лет назад первая версия с RPC была заменена на однонаправленный поток данных сервер-клиент
