Можно ли использовать событие unload для надежного запуска запроса ajax?
Мне нужен метод для мониторинга пользовательских сессий редактирования и одно из решений, которое я В m reviewing я использую событие unload , чтобы отправить ajax-запрос для информирования сервера об окончании сеанса редактирования. (См .: Мониторинг пользовательских сеансов для предотвращения конфликта редактирования )
Мое (довольно ограниченное) чтение события unload указывает на то, что коды, прикрепленные к этому обработчику, должны выполняться быстро, и как таковой обычно используется для очистки объектов, чтобы предотвратить утечки памяти.
У меня вопрос: может ли эта работа быть достаточно надежной для этой цели? [Тысяча двести шестьдесят-восемь] PS. Я знаю об опции async: false .
3 ответа
Этот метод достаточно надежен, если ваш сервер достаточно быстр, чтобы отвечать. Что-то действительно остерегаться все же. Если вы закроете браузер и отправите запрос AJAX в случае выгрузки, есть очень большая вероятность, что ответ не вернется с сервера вовремя, прежде чем объект окна будет уничтожен. Что происходит в этом случае (по крайней мере, с IE), так это то, что он потеряет ваш объект подключения и не завершит его правильно, пока не истечет время ожидания подключения.Если на вашем сервере не включена поддержка соединения, после того, как вы закроете 2 окна (при открытом еще одном окне), у вас закончатся открытые соединения с сервером (для IE6-7, для IE8 - 6 окон) и вы не сможете открыть свой веб-сайт, пока не истечет время ожидания соединения.
Я столкнулся с такой ситуацией раньше, когда я открывал всплывающее окно, которое отправляло запрос AJAX при выгрузке, это было очень надежно, но страдало от описанной выше проблемы, и это заняло у меня очень много времени. чтобы отследить его и понять, что происходит. После этого, что я сделал, я убедился, что открывающееся окно будет иметь тот же код для вызова сервера, и при каждой выгрузке проверял открыватель и запускал там код, если он присутствовал.
Похоже, что если вы закроете самое последнее окно браузера, IE нормально разорвет соединение, но если открыто еще одно окно, этого не произойдет.
P.S. И просто чтобы прокомментировать ответ выше, AJAX на самом деле не асинхронный. По крайней мере, реализация JS этого не делает. После того, как вы отправите запрос, ваш JS-код все еще будет ожидать ответа от сервера. Это не заблокирует выполнение вашего кода, но, поскольку серверу может потребоваться некоторое время для ответа (или достаточное время для Windows, чтобы завершить объект окна IE), вы можете и, вероятно, столкнетесь с проблемой, описанной выше.
У нас есть случай, когда нам это нужно. Это страница отчета, которая требует серьезной памяти на сервере, поэтому мы хотели освободить ее сразу же, как только они покинут страницу. Мы создали набор фреймов и добавили туда обработчик выгрузки. Самым надежным способом было установить src изображения для скрипта освобождения. На самом деле мы использовали как unload, так и onbeforeunload для кроссбраузерной совместимости. Это не работало в ночных клубах веб-комплекта, но руководство не возражало против этого.
Однако это не было предложенным мной решением. Я бы использовал подход сердцебиения, который требует больше работы, но гораздо более надежен.
Ваша страница должна периодически отправлять запросы сердцебиения. Каждый запрос устанавливает последний пульс со страницы. Затем вам понадобится поток, который запускается на сервере и очищает память, если последний пульс был слишком давно.
Это не решает проблему долгого закрытия страницы. Для этого вам нужно немного отслеживать активность пользователя и покинуть эту страницу после периода бездействия (убедитесь, что вы подтвердили это у пользователя)
Вы должны самостоятельно проверить, работает ли ваш конкретный сценарий с тем временем, которое у вас есть на выгрузку, но запрос AJAX выполняется довольно быстро, поскольку AJAX является асинхронным. Вы просто отправляете запрос, и все готово! (Возможно, вам придется очистить только что созданный объект запроса.)
Если вы хотите убедиться, что запрос AJAX был выполнен, вам придется больше беспокоиться/использовать async:false Опция (например, указывает это обсуждение). Но просто отправка — это быстрая операция «бум и все готово».