Как инициализировать сессию в PHP?

В дополнение - как организовать доступ из php к J2EE аппсерверу? К Веблоджик, например? Кто-то так делал?

А.З.ф.И.> Как люди сессию к нему инициализируюут?

Внезапно: php.net/session_start.

А.З.ф.И.> Скажем, кто-то загружает mysite.com/requestform.php, что должно быть прописано в requestform.php для того, чтобы понять, что это новая сессия и сделать какие-то действия по этому поводу.

Там по ссылке все примеры есть. Ну и по see also.

А.З.ф.И.> И кстати, можно ли прописать, что делать, когда сессия expires?

PHP работает не событийно. Каждый запрос от клиента — это формирование полностью нового окружения. Так что можно только проверить состояние сессии. Но не сделать что-то активное. Т.е. в теории можно и на PHP демона какого-то изобразить, но так не делают.

А.З.ф.И.> Сорри за глупый вопрос, давно не занимался php.

На офсайте очень богатая документация с массой примеров, в том числе — от пользователей. По-моему, подобная инфраструктура у PHP наилучшая, по сравнению с прочими языковыми проектами. Достаточно написать в строке браузера php.net/

А.З.ф.И.>> Как люди сессию к нему инициализируюут?
Balancer> Внезапно: php.net/session_start.

Спасибо. Конечно, надо не лениться и RTFM, но вот как-то внезапно схватило, хотелось сделать быстро.

А.З.ф.И.> В дополнение - как организовать доступ из php к J2EE аппсерверу?

Только через какой-нибудь сетевой интерфейс (скажем, XML/JSON RPC) или сокет.

Но есть вариант — попробовать поднять под J2EE Quercus от Resin. Это PHP на JVM. Почти 100% совместим с PHP, такая же скорость + возможность напрямую делать вызовы JVM.

Под Resin Quercus родной, под Tomcat поднимается на уровне работы с конфигами.

Balancer> Но есть вариант — попробовать поднять под J2EE Quercus от Resin. Это PHP на JVM. Почти 100% совместим с PHP, такая же скорость + возможность напрямую делать вызовы JVM.

В принципе, я на JSP сейчас перетаскиваю этот проектик. Это мелкий учебный проект, так что php не обязателен. Ты, кстати, не пользуешь jsp случаем? Вообще, jsp мне как-то кажется ближе и роднее, хотя почему-то все юзают php - наверное, есть причины помимо кучи библиотек.

А.З.ф.И.> Ты, кстати, не пользуешь jsp случаем?

Нет пока. На самом деле, хоть не про JSP, но про JVM подумываю. Есть мысли попробовать частично начать переезд нагруженных компонентов на Play framework. Если к нему удастся Quercus прикрутить, то переезд вообще поэтапным можно делать, тупо запустить свой фреймворк под ним, а потом части переносить на чистую Java, Scala или JBForth. Но пока это область чистых интересов, всё равно бутылочное горлышко в моих проектах — базы данных, а не производительность виртуальных машин.

А.З.ф.И.> хотя почему-то все юзают php - наверное, есть причины помимо кучи библиотек.

Тут много причин:
— Инерция рынка, охват хостингов. PHP сегодня в каждой дырке есть, а JVM требует выделенного сервера. Что начинающие программисты себе позволить часто не могут. Соответственно, начать с PHP им проще
— Входной порог в язык сильно ниже. Начать писать работающий код можно практически сразу. Пусть он и ужасен и уязвим будет, но — будет работать.
— Много достаточно отработанных и популярных готовых решений. На PHP широкий выбор хороших форумов, CMS, фотогалерей и т.п. На JVM-based с этим сильно хуже. Фактически там масса качественных библиотек, но готовые проекты народ всё больше пишет сам под себя.
— Лёгкий цикл отладки. Поменял строчку, нажал F5 в браузере — готов результат. Хотя JSP сейчас к этому ближе, но там есть свои заморочки. Именно потому мне Play framework и нравится — там реализовано PHP-like поведение. Поменял код хоть Java, хоть Scala-компонента, и при запросе он прозрачно для тебя сам перекомпилится.

Balancer> Но пока это область чистых интересов, всё равно бутылочное горлышко в моих проектах — базы данных, а не производительность виртуальных машин.

С точки зрения производительности - конечно, но с точки зрения разделения кода? Как-то некузяво писать бизнес-логику в том же лайере, что и view.

А.З.ф.И.> С точки зрения производительности - конечно, но с точки зрения разделения кода?

На PHP в приличных системах никто не смешивает представления с логикой Есть масса готовых MVC-фреймворков. От популярных, типа Yii или Symfony до моего BORS

А.З.ф.И.> Как-то некузяво писать бизнес-логику в том же лайере, что и view.

Всё правильно. При чём в приличных фреймворках (типа моего BORS ) можно view делать на разных шаблонизаторах, не обязательно базирующихся на HTML. Тот же упомянутый HAML.

Balancer> Всё правильно. При чём в приличных фреймворках (типа моего BORS ) можно view делать на разных шаблонизаторах, не обязательно базирующихся на HTML. Тот же упомянутый HAML.

Не понял. Где крутится то, что реализует у тебя бизнес-логику? Тут же, в пространстве веб-сервера, правильно?

А.З.ф.И.> Где крутится то, что реализует у тебя бизнес-логику? Тут же, в пространстве веб-сервера, правильно?

Естественно. Просто код лежит в одних файлах, шаблоны — в других. При этом view может собираться автоматически, задачи controller'а часто, вообще, берёт на себя фреймворк. Иногда достаточно только схематично описать модель. И даже не на PHP — мне всё больше YAML нравится

А.З.ф.И.>> Где крутится то, что реализует у тебя бизнес-логику? Тут же, в пространстве веб-сервера, правильно?
Balancer> Естественно. Просто код лежит в одних файлах, шаблоны — в других.

Ну, это не есть кул, имхо. Бизнес-логика должна быть на апп-сервере, в отдельной JVM. В целях упорядочения и недопущения.

А.З.ф.И.> Ну, это не есть кул, имхо. Бизнес-логика должна быть на апп-сервере, в отдельной JVM. В целях упорядочения и недопущения.

Ну, это совсем уже другой уровень. Безусловно, системы такого масштаба так и делают. Но это весьма узкий сектор рынка

А.З.ф.И.>> Ну, это не есть кул, имхо. Бизнес-логика должна быть на апп-сервере, в отдельной JVM. В целях упорядочения и недопущения.
Balancer> Ну, это совсем уже другой уровень. Безусловно, системы такого масштаба так и делают. Но это весьма узкий сектор рынка

Хм. А как ты делаешь в PHP? Скажем, тебе нужно, чтоб параллельно HTTP запросам что-то крутилось постоянно. Т.е. оно не вызывается HTTP запросом, оно служит сервисом для HTTP запросов - где-нибудь в отдельном треде. Как ты имплементируешь такие вещи в PHP?

А.З.ф.И.> Хм. А как ты делаешь в PHP? Скажем, тебе нужно, чтоб параллельно HTTP запросам что-то крутилось постоянно.

HTTP (мы же о Web'е?) по своей сути сессионный протокол. Коннект-запрос-ответ-дисконнект. Поэтому все запрашиваемые данные тоже отдаются одной сессией. Если нужно производить на сервере какую-то фоновую обработку данных, то этим занимаются серверные скрипты, которым не нужно взаимодействовать с клиентом прямо.

А.З.ф.И.> Т.е. оно не вызывается HTTP запросом, оно служит сервисом для HTTP запросов - где-нибудь в отдельном треде.

Боюсь, что у нас тут сильно различное концептуальное восприятие. Попробуй сформулировать более конкретный пример, на практике.

А.З.ф.И.>> Хм. А как ты делаешь в PHP? Скажем, тебе нужно, чтоб параллельно HTTP запросам что-то крутилось постоянно.
Balancer> HTTP (мы же о Web'е?) по своей сути сессионный протокол. Коннект-запрос-ответ-дисконнект. Поэтому все запрашиваемые данные тоже отдаются одной сессией.

Ну, понятно, но не вся бизнес-логика ложится в этот протокол. Случаи бывают всякие.

Balancer> Боюсь, что у нас тут сильно различное концептуальное восприятие. Попробуй сформулировать более конкретный пример, на практике.

Ну хотя бы просто запрос, который длится долго. HTTP request приходит, но немедленно выполнить нельзя. Ложим запрос в очередь на выполнение демону, выдаем страничку - "Ждите ответа...".

А.З.ф.И.> Ну, понятно, но не вся бизнес-логика ложится в этот протокол.

Но мы-то обсуждаем Web. А он базируется на HTTP

А.З.ф.И.> Ну хотя бы просто запрос, который длится долго. HTTP request приходит, но немедленно выполнить нельзя. Ложим запрос в очередь на выполнение демону, выдаем страничку - "Ждите ответа...".

HTTP — сессионный. Мы не можем что-то выдать, сказать «ждите», а когда готово, со стороны сервера инициировать какое-то событие «получите результат». Сервер, вообще, не может инициировать соединение с клиентом ни в каком виде. Поэтому возможны только два сценария:

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

2. Клиент шлёт тяжёлый запрос. Сервер просекает это, кидает клиенту лёгкую заглушку, отсоединяется и уходит на обработку. Клиент после этого, во время работы сервера, через AJAX или просто релоадами периодически дёргает сервер спрашивая «ну как там, готово?» (или при тупых релоадах просто получает раз за разом заглушку). Когда сервер готов, то он, наконец, отвечает клиенту на очередном запросе последнего результатом.

Это «современный» вариант. На Авиабазе так сейчас генерация превьюшек сделана, рассылка нотификаций об обновлениях топиков (сейчас отключена) на e-mail и xmpp. Со временем, наверное, все тяжёлые операции нужно на такое перевести, чтобы видимая отзывчивость сервера была выше.

На серверах с логикой JVM-подобных систем обычно реализуется запуском отдельного треда, который и займётся работой. В то время, как основной тред закроет соединение.

На серверах с сессионной логикой (в т.ч. с PHP) понятие сервера в какой-то степени расширяется на всю машину. Процесс, который занимается первичной обработкой запроса тем или иным способом формирует задачу и извещает о ней того или иного исполнителя. Скажем, может положить запись в БД, которую оттуда возьмёт cron-скрипт. Или отправит сообщение в gearman, а с него снимет отдельный демон (мой вариант). Дальше процесс-инициатор закроется. Процесс-обработчик положит результат куда надо и при очередном «проверочном» запросе основной скрипт обнаружит результат, отдав его клиенту.

Balancer> HTTP — сессионный. Мы не можем что-то выдать, сказать «ждите», а когда готово, со стороны сервера инициировать какое-то событие «получите результат». Сервер, вообще, не может инициировать соединение с клиентом ни в каком виде.

Естественно. Но разговор-то не о том. Впрочем, я понял, ты gearman'ом пользуешься - безусловно, вариант. Но я думал, может, у php есть какие-то методы выделения "сервис методов" в отдельные треды.

А.З.ф.И.> я думал, может, у php есть какие-то методы выделения "сервис методов" в отдельные треды.

У него сама идеология другая. Если в Java всё в одной виртуальной машине, и сервер, и обработчики, то в PHP «виртуальная машина» расширяется до всего компа, сервер — сторонний (apache/lighttpd/nginx) и запросы обрабатывают не треды одного процесса уже, а самостоятельные процессы.

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

Balancer> зато, да, болит голова о межпроцессном обмене данных и инициализации среды исполнения при каждом запросе.

Я себе и то и другое законфигурил, на всякий случай, ибо у php очень богатые библиотеки, но пользовать буду в основном jsp, думаю. JSP все-таки мне роднее.