Ждут ли друг друга post запросы по одному адресу?

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

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

В любом случае тебе придется проверить и обеспечить блокировки любым из доступных способов.

Если будешь стартовать сессию, то будут последовательно, если нет, то нет.

http://stackoverflow.com/questions/1430883/simultaneous-requests-to-php-script

Только если файлами. А если сессия в БД, то даже транзакции не спасут.

Сессия есть стандартная симфониевская.

https://www.leaseweblabs.com/2014/08/session-locking-non-blocking-read-sessio...

А вот тут написано как отключить блокировку для симфони. Надо проверить http://garethmccumskey.blogspot.com/2009/10/php-session-write-locking-and-how...

UB

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

Это понятно. Но раз есть обертка то должны быть и способы работы с ней.

Последовательность в асинхронной среде безумная затея - ничто не гарантирует само по себе последовательность выполнения. И не может гарантировать.

Есть только запрос-ответ.

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

Характерные неэффективные модели в такой архитектуре: пуллинг.

И никто так и не заметил, что это еще и от способа запуска php зависит. Если на сервере какой-нибудь nginx с php-fpm, на в нем ограничение на инстансы в конфиге пула прописано, то, может быть, очень даже последовательно выполнится.

Но, вообще, да, крайне неразумно на это закладываться. Если нужно последовательное выполнение, надо самому о блокировке озаботиться. Хотя бы:

$fd = fopen('/tmp/aaa', 'w+');
if ($fd) {
    flock($fd, LOCK_EX);
}

Да нет, я как раз позаботился. Но вот из браузера не удается добиться одновременного запуска двух процессов.

Чтобы один exec начал работать пока работает другой.

При запуске из консоли при этом успеваю запустить параллельное исполнение.

остановился на

            /**
             * @var $session \Symfony\Component\HttpFoundation\Session\Session
             */
            $session = $this->get('session');
            // Change the session attributes
            $session->save();
……………………
            header('Content-type: application/json');
            echo json_encode(array('status' => $status, 'message' => join('\n', $output)));
            exit;

К сожалению при завершении сессии стандарные симфониевские ответы падают с ошибкой.

Искать ошибку не стал — откатился к php.

Вопрос будут ли эти пост запросы ФАКТИЧЕСКИ выполняться последовательно? Или есть шанс что второй запрос начнет выполняться до окончания первого?

Начнём с того, что нет гарантий, что они ДОЙДУТ последовательно. Да и того, что они дойдут оба.

Отсюда ответ: нет, никаких и не надейся.

У тебя race condition между if и flock. И php не даст эксепшн. Если я правильно его понимаю, то нужно проверять статус возврата flock.

ФАКТИЧЕСКИ запросы всегда выполнялись последовательно, ДО изменений в указанном мной посте.

Теперь запросы выполняются параллельно — новый стартует до окончания предыдущего. ЦЕЛЬ ДОСТИГНУТА.

Большое спасибо за указание на то что старт сессии вызывает неявную блокировку. Кроме того теперь стало понятно откуда откуда возник прикол с REST и его требованием не использовать сессии.

У тебя race condition между if и flock. И php не даст эксепшн.

Объясни.

fopen одного и того же файла работает если он не залочен, так?

Ты проверяешь, открылся ли он. Окей.

Потом лочишь.

Допустим есть 2 треда, тогда может быть такая гонка:

1: $fd = fopen('/tmp/aaa', 'w+'); //ok
2: $fd = fopen('/tmp/aaa', 'w+'); //ok, открывать файл для w+ можно 2 раза
1: if ($fd) { //ok
2: if ($fd) { //ok
1:    flock($fd, LOCK_EX); // ok
2:    flock($fd, LOCK_EX); // ← fail но ты не проверяешь его статус (а exception он не кидает). Скрипт будет идти дальше.
}

А зачем его проверять? Оно же внутри вешается, ждет освобождения лока.

P.S. Кстати, полезно иногда мануалы перечитывать. Оказывается, оно теперь лок при закрытии файла не освобождает. А я и не знал.

Вейт, оно блокирует по дефолту?

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

Ну вообще-то оно именно для файлов. Открыть, залочить, записать, отлочить и закрыть. Не такой уж и редкий юзкейс.

Ну и так-то оно просто повторяет интерфейс man 2 flock, без ненужных собственных абстракций.

Просто если что-то произойдёт с локом, тред (в php нет green-тредов?) же будет висеть достаточно долго. Со всеми вытекающими.

По умолчанию — 30 секунд. Потом сдохнет. Но вот чем мне php нравится, если захотеть, то он не помешает прострелить себе ногу.