Различные библиотеки, использующиеся в PHP для доступа к хранилищам данных, предоставляют возможность создания постоянных соединений (pconnect, или persistent connect). В их число входят mysql, postgresql, memcache и другие. Использование этих функций сулит нам экономию на время установления соединения. Но какой ценой ?
Возьмем для примера MySQL. Созданные соединения находятся в pool-е, а так как mysql не умеет очищать их до состояния, идентичного состоянию нового connection-а, есть вероятность, что на запрос mysql_pconnect() клиент получит соединение с "мусором". Например, с установленными локальными переменными, кодировками, временными таблицами и т.д.
Вторая проблема может проявится при таком сценарии развития событий. Клиентом была открыта транзакция, но в результате Fatal error или прерывания по времени, небыла вызвана функция commit или rollback. Так как транзакция привязана к соединению, она так и останется "висеть" и будет передана другому клиенту. Это черевато блокировкой других транзакций. В случае обычного connect-а, при аварийном завершении скрипта произошло бы закрытие соединения с rollback-ом всех незавершенных транзакций. Схожее поведение проявляется для временных таблиц и при устанвке блокировок.
Необходимо отметить, что эти эффекты можно наблюдать, когда PHP работает как модуль к Apache или как FastCGI приложение. В случае исполнения PHP в CGI режиме, pconnect будет вести себя так же, как и обычный connect т.к. отсутствует master процесс и pool будет уничтожаться каждый раз при завершении работы скрипта.
В итоге, нужно хорошо проанализировать архитектуру системы вцелом, чтобы решить, использовать ли постоянные соединения, учитывая, что в случае локального расположения БД, временнАя стоимость подключения достаточно мала. Функция connect может быть использована в 90% случаев, сократив тем самым количество фантомных ошибок, трудных для воспроизведения и анализа.
