PHP session_start сериализует и блокирует все остальные, использующие один и тот же сеанс.

Question

сеанс должен быть синхронизирован. Когда A пишет/сохраняет значение sessionB или another A ожидание. Это необходимо для обработки сеансов на основе файлов.

Но однажды A загрузил сеанс (но теперь сохранил его модификации) B также должно быть разрешено загрузить один и тот же сеанс. потому что загрузка откроет файл и приведет содержимое файла в память и закроется.

Есть ли причина блокировать все остальные скрипты в течение всего времени A загружает сеанс и A сохраняет сеанс. не может ли синхронизация выполняться только с помощью обработчика сохранения?

Так что два скрипта PHP никогда не могут работать одновременно. Если они используют один и тот же сеанс.

, например seslock.php

<?php 
header('Content-Type: text/plain'); 
session_start(); 
if(isset($_GET['wait'])){ 
    sleep(30); 
    echo "waiting\n"; 
}else{ 
    echo "No Waiting\n"; 
} 
?> 
done 

визит seslock.php немедленно ответить, но seslock.php?wait займет 30 секунд, чтобы ответить. Но проблема в том, что вы сначала запрашиваете seslock.php?wait и только seslock.php секунд. событие, то блок non-sleep попросит вас подождать 30 секунд.

Почему этот блок не является моим вопросом. Я спрашиваю, почему он блокирует start to save? вместо блокировки only save?

Answer 1

Возможные дубликатами:

How does session_start lock in PHP?

Why does session_start cause a timeout when one script calls another script using curl

session_start hangs

How to kill a PHP session?

... И много;)

Edit

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

2. Средства для этого может быть обработчик PHP сеанса в session_write_close() в pointed by this post

3. How to prevent blocking php requests, by Konr Ness

Answer 2

по умолчанию производится сериализация изменения сеанса для каждого идентификатора сессии. Это обеспечивает гарантированное согласованное состояние сеанса в ваших сценариях.

Вы можете отказаться от этого преимущества, запустив session_write_close() сразу после session_start(). Это также делает сеанс только для чтения.

В качестве альтернативы вы можете написать собственный обработчик сеанса без блокировки.