Так именно это и хотел сказать многоуважаемый гость. Не? Это отдельная тема и проблемы блокировки сессий один из мелких нюансов. При правильной архитектуре приложения эти проблемы решаются вовсе не блокировками или их отсутствием. Они решаются правильной постановкой задач и грамотным их решением.

Я не понимаю, в чем он не прав. Я сейчас думаю что тоже смог бы решить любую проблему сессий, которая будет озвучена. И вовсе не её блокировкой. Фиг с ней, асинхронностью. Попробуем решить реальную проблему. Ну?

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

sergeiss

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

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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

Ну так то да. Хотя это скорее архитектура фронтэнда. Я же говорил, если есть такая жесткая необходимость запустить один и тот же скрипт (пусть даже не один и тот же) одновременно, то нужно это решать на стороне сервера. Он нашел ткой выход из положения, я кстати взял на карандашик, за что ему спасибо. Однако тот самый аноним тоже прав, не нужно так все воспринимать однобоко. Ведь это вы упрекнули меня (?) в восмибитном мышлении.

select for update не канает. Ведь второй скрипт может еще "думать", пока первый получает данные.

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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

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

Вообще то я уже не про сессии говорил, а про архитектуру в условиях "конкурентных запросов" (буду пользоваться вашей терминологией). Тут дело вовсе не в сессиях. Реализация хранения их в базе с соответствующей блокировкой, это уже частный случай решения. Однако такая блокировка не есть блокировка хранилища, о чем я и говорил. И не важно, как это реализовно, можно поставить на время локирующий файлик или с мемкэшем заморочиться. Важно, что это уже блокировка скрипта. Именно вот это:

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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

Опять же что именно блокировать. Хранилище или сам скрипт. Или скрипт в зависимости от состояния хранилища. В случае с примером ТС отказываться от блокировки на мой взгляд решение по пути наименьшего сопротивления. Он увидел локальную проблему, нашел сиюминутный выход и объявил это гениальным решением.

Я вот придержусь все же другой стороны - не нужно ничего разблокировать бездумно. Ибо это сродни валидации по принципу запрещения. Если действительно требуется отработать (кстати, а почему асинхронность и конкурентность?) синхронные запросы, вот тогда и стоит начинать задумываться о снятии блокировок. Либо о внештатных блокировках. Это оправдано. В других случаях это дутьё на воду после парного молока.

Стоит сто раз пересмотреть возможные варинты фронтэнд прежде чем махать топором с плеча на блокировки.

Мне к примеру не нравитится принцип эксепшенов. В частности отсутствие возможности продолжить код. Я нашел бы этому приминение - увы. Но меня вот раскритиковали прошлый раз за альтернативу.

UPD Вот этот момент в статье ТС

, особенно в первой части, решает 99,99% случаев возможного возникновения таких казусов. О чем вообще сыр-бор...



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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

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

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

Итак примеры данных

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

для очередей когда нужно последовательно вызвать данные есть $.when в jQuery например, и подобный механизм там где нужно используется на все 100 процентов