обрабатывать HTTP-тайм аут для ajax save

Question

У меня есть приложение JavaScript, которое регулярно сохраняет новые и обновленные данные. Однако мне нужно, чтобы он работал и на медленном соединении.

Данные передаются в одном HTTP-запросе HTTP. Ответ будет возвращать вновь вставленные идентификаторы для вновь созданных записей.

Что я нахожу, так это то, что представленные данные полностью сохранены, однако иногда результат возврата истекает. Поэтому приложение-браузер не знает, что данные были отправлены успешно и попытается сохранить его снова.

Я знаю, что могу обнаружить тайм-аут в браузере, но как я могу убедиться, что данные сохранены правильно?

Какие хорошие методы обработки этого случая?

Я вижу здесь https://dba.stackexchange.com/a/94309/2599, что я мог бы включать в себя состояние ожидания:

• Получить номер транзакции с сервера
• передачу данных, будет сохранен в ожидании на сервере
• , если в ожидании транзакции уже существует, то сделать не переписывать данные, но отправлять те же результаты назад
• если получен успех, совершить незавершенную транзакцию
• если ошибка, повторите попытку
• если тайм-аут, повторите попытку

Однако я ищу более простое решение?

Answer 1

Действительно, кажется, вам нужно понять, почему клиент считает, что данные не были сохранены, но на самом деле это было. Если проблема является чисто одной из сроков, то, возможно, время ожидания клиента просто необходимо удлинить, чтобы оно не сдавалось слишком рано или количество данных, которые вы отправляете обратно в ответ, должно быть уменьшено, чтобы ответ возвращался быстрее на медленной ссылке.

Но, если вы не можете избавиться от проблемы, путь, есть куча возможностей для программирования вокруг вопроса:

1. Сервер может отслеживать последние сохранить запрос от каждого клиент (или хэш такого запроса), и если он видит, что дублирующий запрос сохранения поступает от одного и того же клиента, он может просто вернуть что-то вроде «уже сохраненного».

2. Поток кода на сервере может быть изменен таким образом, что небольшой ответ отправляется обратно клиенту сразу после выполнения операции с базой данных (без задержек для любых других типов операционных операций), тем самым уменьшая вероятность что клиент будет тайм-аут после сохранения данных.

3. Клиент может создать уникальный идентификатор для каждого запроса на сохранение, и если сервер видит один и тот же идентификатор сохранения, который используется для нескольких запросов, он может знать, что клиент считает, что он просто пытается сохранить эти данные снова.

4. После любого типа сбоев, перед повторной попыткой клиент может запросить сервер, чтобы увидеть, удалось ли предыдущая попытка сохранения или не удалось.

Answer 2

У вас может быть несколько попыток подсчета как простой глобальный int. Вы также можете автоматически повторить попытку, но это не подходит для приложения для автоматического сохранения. Третьим вариантом является использование auto-save plugins for jQuery.

Answer 3

Несколько предложений

• Увеличение тайм-аут, не обрабатывают тайм-аут, как успех.
• Вы можете сбросить выходные данные каждой записи, как только сможете получить ob_flush и flush.
• Поскольку вы делаете запрос в регулярном интервале. Проверьте метод connection_aborted на каждый вызов API, если клиент отключился, вы можете сохранить ответ в файле temp, а при следующем запросе вы можете добавить последний ответ с новым ответом, но этот метод больше потребляет ресурсы.