Максим Ленский, логика такая:
1) ты хэндлишь клик по ссылке, превентишь ее действие, читаешь ее урл (он должен быть the same domain вроде как)
2) делаешь window.history.pushState({}, '', url)
какой из этих шагов не работает? и как ты замеряешь что работает/не работает
ince, написано же, на примере кипячения чайника - значит это и относится к асинхронно, с рубашкой неважно. Суть асинхронности такова, что ты не дожидаешься от метода сигнала его завершения (прерывания) и исполняешь логику представив что он завершился (но по факту он может быть "в процессе").
вот так new Promise(resolve=>setTimeout(resolve,1e3))
promise придумали не для этого, а разделения очереди на макротаски (settimeout) и микротаски (promise)
если все так как ты описал, то равновероятно же
если это не устраивает, то можно вести словарь, ключ - число, значение - кол-во выпаданий, тогда кол-во выпаданий/общее число экспериментов
Петр, +1 заводить на каждое соединение по потоку - полный бред, траты на стэк + время на свитч контекста... подход типичного джависта, по-другому не звать
Leo_Eldorado, мне видится реализация так:
1) Брокер сообщений (kafka/rabbit)
2) Микросервис gateway который принимает запросы (stateless)
3) Микросервис бизнес-логики который пишет в БД
Для веба лучше всего в таком кейсе подойдет веб-сокет или поллинг, поскольку мы не знаем заранее когда операция выполнится (бывают операции постоения отчетов которые могут длиться несколько часов).
Веб-клиент делает запрос на гейт, который в свою очередь формирует сообщение для брокера в определенную очередь и отсылает, в ответ клиенту приходит id сообщения статус которого нужно проверять (скажем через простой поллинг раз в 10 сек). Микросервис БЛ уже подписан на определенную очередь и просто обрабатывает сообщения все подряд, при поступлении очередного он делает все что нужно с БД и результат кладет в другую очередь. Далее можно идти по нескольким путям:
- gateway уже подписан на очередь результатов и вычитывает результат, хранит у себя в кэш какое-то время (выставляется ТТЛ), соответственно веб-клиенты при очередном цикле поллинга получат обновленный статус. Этот кейс подходит когда статус могут читать много клиентов и не нужно при первом обращении его удалять из кэша (тут кстати привет redis)
- gateway по запросу делает хук на очередь и читает с нужным id статус. Тут скорее всего при вычитывании сообщение удалится из очереди (хотя насколько помню как настроишь) и статус для других клиентов уже будет недоступен (или его опять же где-то хранить)
Leo_Eldorado, стоп, я говорю в терминах транзакций .net с сервером транзакций, он там умеет намного больше чем транзакции БД.
Если говорим в терминологии транзакций БД, то флоу такой:
1) Запрос на сервер
2) Перед коммитом/откатом сервер формирует и отправляет ответ
3) Клиент приняв ответ делает доп запрос на коммит/откат, вот его уже можем повторять несколько раз в случае обрыва связи, потому что он в очередном (повторном) случае вернет предыдущий результат (другими словами можно вызывать 10 раз коммит для одной и той же операции, он со 2го раза начнет отдавать то что выдал на 1м вызове)
Но это все жуткий геморрой, советую смотреть в сторону брокеров сообщений, учи что такое подписка на события и делай обработку фейла внутри одного микросервиса, и только в случае успеха/неуспеха шли на шину
Leo_Eldorado, не во всех случаях это возможно, давай допустим что у тебя есть вцф клиент и есть вцф сервер, ты с вцф клиента хочешь исполнять операцию. Сервер у тебя пишет в БД. Вот кейс когда это не будет работать:
1. Клиент отправил запрос
2. Сервер принял запрос и начал писать в БД
3. Клиент-сервер потеряли связь
4. К моменту когда сервер запишет в БД и захочет вернуть результат клиенту связь еще не будет восстановлена
5. Ответ на сервере теряется
6. Клиент восстанавливает связь
С точки зрения коммуникации и обработки бизнес-логики таких конкурирующих кейсов не один, для упрощения таких ситуаций придумали Pub/Sub и брокеров RabbitMQ, Kafka.
например где тут используется location?