Вопрос по LOCK/UNLOCK TABLES и PHP как FASTCGI

[Scud]

Вопрос по LOCK/UNLOCK TABLES и PHP как FASTCGI

Вот возник у меня такой вопрос: в MySQL с помощью LOCK/UNLOCK TABLES можно блокировать таблицы на чтение и на запись, блокировки эти PER THREAD, т.е. как я понимаю пока один поток пишет, другие ждут. Но что будет если у меня PHP работает через mod_fastcgi, т.е. куча запросов от клиентов обрабатывается одним и тем же php, т.е. одним thread, получается что в такой конфигурации эти блокировки бесполезны? И лучше использовать user level lock? Можеть кто-нибудь подтвердить или опровергнуть мои выводы

-~{}~ 19.11.05 17:50:

Ну что ж продолжаю монолог Внимание грабли!
Для persistent соединений:
-----------------------------------
Если вы поставили LOCK на таблицу, потом случайно отвалились без UNLOCK, то таблица останется залоченой и никто туда уже ничего не запишет (очевидно пока не умрет mysql'ый thread залочивший таблицу).

Для обычных соединений:
----------------------------------
Unlock будет происходить автоматически при закрытии соединения, так что единственное что вам грозит если вы отвалитесь в середине некой многошаговой (много-insert'ой) операции записи данных в базу, так это несогласованность данных в таблице (таблицах). Зато никаких блокировок не останеться.

Вывод: для чтения лучше использовать persitent соединения, для записи с блокировкой лучше использовать обычные соединения.

 

[alpine]

Scud
Внимание! На форуме есть поиск.
LOCK

-~{}~ 20.11.05 15:56:

Но что будет если у меня PHP работает через mod_fastcgi, т.е. куча запросов от клиентов обрабатывается одним и тем же php, т.е. одним thread, получается что в такой конфигурации эти блокировки бесполезны? И лучше использовать user level lock? Можеть кто-нибудь подтвердить или опровергнуть мои выводы

Нет. Каждый раз создается новый thread. Лучше использовать транзакции(innodb в mysql, postgres).

Вывод: для чтения лучше использовать persitent соединения, для записи с блокировкой лучше использовать обычные соединения.

Для mod_fastcgi ты не можешь использовать [m]mysql_pconnect[/m]
Выводы: прежде чем делать выводы нужно внимательно читать документацию.

 

[Scud]

Ну с такими выводами сложно не согласиться
Но не будет ли любезен многоуважаемый джин показать мне где это написано про mod_fastcgi и pconnect, просто я вот работаю с PHP через mod_fastcgi, а с БД работаю с помощью PEAR:B и везде указываю DB::connect($dsn, array('persistent' => TRUE)), и нормально всё так пашет.

 

[Falc]

Вообще-то скорость коннекта к MySQL достаточно высока, так что можно вообще не использовать постоянные соединения, тем более что в расширении mysqli их вообще нету.

 

[alpine]

Scud
Постоянные соединения с базами данных

Первый способ заключается в том, чтобы использовать PHP как CGI-оболочку. При этом PHP-интерпретатор создается и уничтожается при каждом обращении к странице (PHP-скрипту). Поскольку интерпретатор уничтожается после каждого запроса к серверу, все используемые им ресурсы (в том числе и соединение с базой данных) закрывается. Следовательно, в этом случае вы не получите ничего от использования постоянных соединений - их просто нет.

Я немного не точно выразился. Ты можешь использовать функцию mysql_pconnect но не можешь использовать постоянные соединения.

 

[Steamroller]

alpine, CGI и FastCGI - разные немного вещи. В FastCGI постоянные подключения вполне себе нормально работают, там же процесс не уничтожается после каждого запроса. Там даже eaccelerator в состоянии работать.

 

[alpine]

Steamroller
Вот сижу читаю про FastCGI и как оно отличается от CGI

 

[Scud]

Тем что в CGI бинарник php поднимается на каждый запрос, а в FastCGI бинарник поднимается один раз, а потом висит в памяти и ждет очередного запроса на обработку. Примерно так.

 

[Falc]

alpine
CGI - каждый раз запускает процесс php который исполняет скрипт просле чего процес завершается
FastCGI - php висит постояно и слушает сокет, веб-сервер подключается к нему предает входные данные, php обрабатывает скрипт возвращает веб-серверу ответ, после обработки остается в памяти и готов обрабатывать следующий реквест.

 

[alpine]

Да. Насчет fastCGI и pconnect был не прав.

-~{}~ 21.11.05 15:55:

Вот нашел один нюанс - PHP_FCGI_MAX_REQUESTS. Это переменная окужения которая определяет кол-во запросов(по дефолту 500) после которого процесс(?) завершает свою работу.

 

[Falc]

alpine
Да можно установить ограницение на кол-во обрабатываемых реквестов. После перезапуска процеса функция pconnect просто откроет новое соединение (как в первый раз).

 

[Scud]

Он не завершает, он перезапускается.
p.s. Предыдущего сообщение не заметил

 

[alpine]

Falc
Которое обслужит еще n request-ов и опять закроется и так у каждого чайлда. Тогда в чем смысл pconnect если он закрывается?

 

[Steamroller]

Он не завершает, он перезапускается.

Сам по себе он не перезапустится, его спец. спавнер должен пускать, либо модуль апачный mod_fastсgi - отдельный процесс держит в памяти, либо lighttpd'шный за этим следит.

Тогда в чем смысл pconnect если он закрывается?

Ну одно дело каждый раз открывать соединение, другое дело - 1 раз в 500 запросов (это по дефолту, реально конечно надо не 500 ставить а сильно больше). Хотя для MySQL пофиг, там соединение мгновенно открывается.

 

[Falc]

alpine
>>Тогда в чем смысл pconnect если он закрывается?
Смысл в том чтобы сэкономить время на подключении к базе, но как уже не раз было сказано, подключение к MySQL очень быстро и толку от такой экономии нету, в то время как добавляются лишние проблемы. Однако например при коннекте к ораклу постоянное соединение очень полезно, т.к. подключение к ораклу может быть очень не быстрым.