Через Кейта — вот проблема, которую я бью себя за то, что я не освещаю явно в AJAX @ localhost — Проблемы с асинхронными Ajax-запросами и PHP-сессиями Марка Вандшнейдера .
Обычно, когда вы пишете веб-приложения на PHP, это на самом деле не проблема, поскольку каждый запрос страницы получает свою собственную среду выполнения, и пользователь посещает только одну страницу за раз. Каждый запрос страницы от конкретного пользователя поступает более или менее последовательно и не передает данные другим запросам страницы.
Однако Ajax меняет все это: внезапно одно посещение страницы может привести к нескольким одновременным запросам к серверу.
Теперь, прежде чем идти дальше — это не проблема PHP, несмотря на заголовок (я надеюсь, что веб-кольцо обращает внимание) — это особенность HTTP — он не имеет состояния. Проблема на самом деле заключается в размытии линий, которые вводит AJAX — это идет прямо к линии между двумя типами AJAX — клиент или сервер управляют состоянием?
Как указывает Кит ;
Короче говоря, серверные технологии, такие как PHP, не позволяют блокировать доступ к сеансу между запросами.
Я бы немного расширил это — короче говоря, при использовании протокола без сохранения состояния, такого как HTTP, любая попытка блокировать ресурсы на стороне сервера между запросами всегда будет уродливым и потенциально опасным взломом. Например, что если клиент подвергается отключению питания вскоре после блокировки чего-либо?
Кроме того, полезным примером является Dokuwiki , который реализует механизм блокировки страниц, чтобы предотвратить проблемы с одновременным редактированием двумя людьми. Это делается с помощью файла «блокировки», который «касается» последней отметки времени, когда вы начинаете редактировать страницу или просматриваете предварительный просмотр. Если сервер не получит от вас ответа в течение 15 минут (по умолчанию), ваша блокировка может быть передана кому-либо еще. На самом деле, это довольно хорошая реализация, поскольку она никогда не приведет к блокировкам «зомби», которые требуют очистки администратором — я не думаю, что есть лучший способ сделать это. Но выбор времени основан на предположениях об очень конкретной задаче, которую выполняют конечные пользователи (редактирование вики-страницы), и 15 минут явно слишком много для типичных вещей, которые люди делают с AJAX. Я не думаю, что этот подход можно перевести на AJAX — его нельзя сделать общим способом.
Грязные воды
Вывод, к которому приходит Марк, вероятно, самый умный;
Теперь, когда мы знаем об этой проблеме и как она может проявиться, следующий вопрос, конечно, как мы ее решаем? К сожалению, я думаю, что это одна из тех проблем, которые лучше всего решить, избегая ее. Встраивание логики и других вещей в наше веб-приложение для блокировки потоков выполнения (т. Е. Отдельных запросов) было бы чрезмерно дорогостоящим и исключало бы большую часть удовольствия и многих преимуществ асинхронных запросов через Ajax. Вместо этого мы избегаем изменения данных сеанса при выполнении нескольких запросов сеанса.
Наряду с тем, что я пытался поднять здесь , это еще одна вещь, на которую вы должны обратить внимание при написании приложений AJAX. Это не должно быть проблемой — это зависит от того, что вы делаете.
Попытка представить это — своего рода общая картина, это что-то вроде «Эй, наша база данных не поддерживает транзакции ACID, но если вы будете осторожны, это не будет иметь значения». Возможно, вы можете сказать, насколько это смешно — возможно, нет (и да — я знаю — <вставьте сюда хорошо известную БД, которая когда-то не проводила транзакции>).
Что неприятно, так это чтение ответов на эту проблему, таких как ответы на освещение AJAXian этого . В частности, парни, которые должны «получить это», явно этого не делают;
Суть PHP в том, что он основан на запросах, а это означает, что хранение информации не является постоянным во всех запросах. Данные сеанса по-прежнему сохраняются / восстанавливаются при каждом запросе. Если вы не можете справиться с этим и нуждаетесь в нескольких асинхронных запросах к приложению для доступа к одному и тому же набору данных (почему это вне меня, есть другие способы кодирования), тогда я предлагаю перейти на платформу J2EE.
Вернитесь к Олд-Кент-роуд. Не пропустите Go. Особенность HTTP заключается в том, что он основан на запросах — независимо от того, сколько EJB-компонентов вы добавите в него!
Проблема здесь действительно специфична для приложений в стиле HTML ++ (клиент / SOA, когда / если это случится, не пострадает от этого, сессия является чисто клиентской) — люди действительно должны знать, что первоначальная простота «Hello World» ! »@ Localhost не переводится как AJAX == просто. Я знаю, что энтузиасты AJAX не хотят слышать о проблемах, но когда все читают с разных листов, а другие играют «Не слышу зла, не говори зла, не вижу зла», мы не продвигаемся вперед в том, что вы можете и можете не делать с этим. Если подумать, то, что AJAX на самом деле сложнее, чем кажется, приводит к требованию экспертов в предметной области — посчитайте это хорошим, если хотите.