PHP blocks session_start while other PHP instance is running

A while ago, I implemented an AJAX-based progress bar on a web page
that executed a lengthy server operation. The web page was a Java
servlet on a Tomcat server. The progress bar worked by repeatedly
querying a secondary "Status" servlet, which returned JSON information
about the progress of the ongoing server operation. The main servlet
communicated with the "Status" servlet through session variables, so
that the status servlet would know the progress of the main servlet's
operation.

Now I am trying to implement the same thing in a different application
in PHP (which I'm more familiar with than Java servlets). Technically,
the whole thing is functional: The main script launches, opens a
session with start_session, then updates the session variables with
the progress of the operation, while the jQuery-based page requests
progress updates from the second script.

However, a fatal flaw is rendering the whole set-up useless: The
server refuses to respond to the AJAX request until the server
operation is complete. While the main script is running, the second
script cannot loaded.

By experimenting a bit, I finally traced this to the "session_start"
command. It seems that while a PHP script is being executed (using
CGI) and has a session open, trying to re-open the same session in
another script will block the second request until the first script
has finished. So the session is useless for acting as a "semaphore" to
exchange information between the two scripts, which is exactly what I
need for my progress bar.

Is there any other possibility of exchanging such information, besides
a database? I'll use the database if I have to, but it seems like a
pretty big performance drag to have to read and write the progress to
and from the database almost every second.

--
Christoph

Re: PHP blocks session_start while other PHP instance is running

Hi,

On Wed, 2 Apr 2008 08:10:22 -0700 (PDT) Christoph
wrote:

> However, a fatal flaw is rendering the whole set-up useless: The
> server refuses to respond to the AJAX request until the server
> operation is complete. While the main script is running, the second
> script cannot loaded.

I'd say the fatal flaw is to have a web server called script do the
lenghty task, but that's just my opinion (not unsubstantiated, though).

After all the built-in file based session mechanism chose to not deal
with concurrent access to session data and thus just locks the session
file until end of request or -- alternatively -- session_write_close().

Since you intend to use sessions as a vehicle for concurrent data
store/retrieval, that's probably not an option which would help you.
Using fine-locked files or databases or shared memory is probably
better for your task. Have a look at shmop_*(), but it might be too
restricted for your task. Otherwise, rely on files, database, ...

-hwh

Re: PHP blocks session_start while other PHP instance is running

On Apr 2, 5:24=A0pm, Hans-Werner Hilse wrote:
> I'd say the fatal flaw is to have a web server called script do the
> lenghty task, but that's just my opinion (not unsubstantiated, though).
>
> After all the built-in file based session mechanism chose to not deal
> with concurrent access to session data and thus just locks the session
> file until end of request or -- alternatively -- session_write_close().
>
> Since you intend to use sessions as a vehicle for concurrent data
> store/retrieval, that's probably not an option which would help you.
> Using fine-locked files or databases or shared memory is probably
> better for your task. Have a look at shmop_*(), but it might be too
> restricted for your task. Otherwise, rely on files, database, ...
>
> -hwh

Mh... I used to sing PHP's praises over Java servlets for some time,
but now that I've worked with an event-based server I'm finding it
difficult to go back. ;)

Anyway, If the task took longer, I'd distribute it over multiple cron
calls - but I'm talking about something between 10 seconds to at most
5 minutes, so it'd be inconvenient to have to schedule it and come
back later. I guess I'll just use the database... though I'll explore
the shared memory thing for a bit.

Thanks!

--
Chris

Re: PHP blocks session_start while other PHP instance is running

Christoph wrote:
> Is there any other possibility of exchanging such information, besides
> a database? I'll use the database if I have to, but it seems like a
> pretty big performance drag to have to read and write the progress to
> and from the database almost every second.
I think most fast way will be shared memory
http://www.php.net/manual/en/ref.shmop.php

If you have to use mysql database use CREATE TABLE ... ENGINE =
MEMORY; to decrease overhead.

Re: PHP blocks session_start while other PHP instance is running

On 2 Apr, 16:10, Christoph wrote:
>
> By experimenting a bit, I finally traced this to the "session_start"
> command. It seems that while a PHP script is being executed (using
> CGI) and has a session open, trying to re-open the same session in
> another script will block the second request until the first script
> has finished. So the session is useless for acting as a "semaphore" to
> exchange information between the two scripts, which is exactly what I
> need for my progress bar.
>
> Is there any other possibility of exchanging such information, besides
> a database? I'll use the database if I have to, but it seems like a
> pretty big performance drag to have to read and write the progress to
> and from the database almost every second.
>
> --
> Christoph

Sounds a bit strange.

Are you running on MS Windows? If so then that might explain it -
MSWin is very heavy-handed in its file locking semantics - so if the
session file is opened at session_start() and not closed till the
sesion is flushed then that would explain it. (it might be the same on
Unix too). It seems remarkable that PHP should work that way though.

If it is due to file locking then the solution is quite simple - just
write your own session handler which does not retain an open file
handle, or use a database bound session handler.

C.