session_start hangs parallel requests for the same session

[Sergei Shelukhin]

Hi. I have a session started in php and two browser windows (IE)/tabs
(FF) open.
In one window, I execute a very slow report, immediately after that, I
execute a fast simple page in another.

I have set up a timer that records time into global variable at the
start of the request,
it outputs three time values in seconds - right before session_start,
right after session_start, and at the very end of the request.
here's what it shows
Slow report that started a second earlier:
DEBUG: Before session start: 0.0115
DEBUG: Session start: 0.0133
DEBUG: End request: 101.9878

"Quick" page that started after it:
DEBUG: Before session start: 0.0114
DEBUG: Session start time: 98.467
DEBUG: End request: 99.084

The same is true for any request count, all of them load as fast as
the slowest one.
What's wrong w/session_start and how do I fix it?

[ZeldorBlat]

On Jun 11, 12:21 pm, Sergei Shelukhin <[e-mail]:

Hi. I have a session started in php and two browser windows (IE)/tabs
(FF) open.
In one window, I execute a very slow report, immediately after that, I
execute a fast simple page in another.

I have set up a timer that records time into global variable at the
start of the request,
it outputs three time values in seconds - right before session_start,
right after session_start, and at the very end of the request.
here's what it shows
Slow report that started a second earlier:
DEBUG: Before session start: 0.0115
DEBUG: Session start: 0.0133
DEBUG: End request: 101.9878

"Quick" page that started after it:
DEBUG: Before session start: 0.0114
DEBUG: Session start time: 98.467
DEBUG: End request: 99.084

The same is true for any request count, all of them load as fast as
the slowest one.
What's wrong w/session_start and how do I fix it?

It's because the first request locks the session file and doesn't
release the lock until the session is closed (at the end of the
request). So, the other pages wait for it to finish. See this note:

<http://www.php.net/manual/en/ref.session.php#64525>

[Sergei Shelukhin]

Thanks, that was it!
However, if I have a standard pattern where session is started and
then closed for writing at the start of every request in one place,
how do I reopen it to write a variable once in a while? I have exactly
two places where I need to do that and if I use session_start there it
shows warnings (cannot send cookie). I can suppress them but it
doesn't seem right

[Jerry Stuckle]

Sergei Shelukhin wrote:

Hi. I have a session started in php and two browser windows (IE)/tabs
(FF) open.
In one window, I execute a very slow report, immediately after that, I
execute a fast simple page in another.

I have set up a timer that records time into global variable at the
start of the request,
it outputs three time values in seconds - right before session_start,
right after session_start, and at the very end of the request.
here's what it shows
Slow report that started a second earlier:
DEBUG: Before session start: 0.0115
DEBUG: Session start: 0.0133
DEBUG: End request: 101.9878

"Quick" page that started after it:
DEBUG: Before session start: 0.0114
DEBUG: Session start time: 98.467
DEBUG: End request: 99.084

The same is true for any request count, all of them load as fast as
the slowest one.
What's wrong w/session_start and how do I fix it?

Sessions are single threaded. If you already have the page open in one
session, PHP will hold any other requests for that same session.

To resolve the problem you need to call session_write_close() in the
long-running task. Of course, after that you won't have access to any
of the $_SESSION variables.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Jerry Stuckle]

Sergei Shelukhin wrote:

Thanks, that was it!
However, if I have a standard pattern where session is started and
then closed for writing at the start of every request in one place,
how do I reopen it to write a variable once in a while? I have exactly
two places where I need to do that and if I use session_start there it
shows warnings (cannot send cookie). I can suppress them but it
doesn't seem right

You don't. Once you close the session, you can't open it again in the
same request.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Sergei Shelukhin]

Eh... How do I fiox the problem and write into session then? Do I have
to write into session files manually?

[Jerry Stuckle]

Sergei Shelukhin wrote:

Eh... How do I fiox the problem and write into session then? Do I have
to write into session files manually?

You can't. It's simply a restriction of how sessions work.

Also, you can't write the session file itself manually, either - if you
tried, results would be highly indeterminate, IMHO.

Maybe you need to use another means to store your data (like an RDB) and
pass the id in the session.

Or perhaps you need to look at how to restructure your code.

But this will only affect someone if they have your site open in two
browser windows (and the same browser - not different browsers).

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Sergei Shelukhin]

Well as a matter of fact it's not a site, it's an intranet app, 99% of
all users open it in multiple tabs and it's bad that session is
basically unusable in php 0_o
I wonder if they are going to fix it in php 6?

[Jerry Stuckle]

Sergei Shelukhin wrote:

Well as a matter of fact it's not a site, it's an intranet app, 99% of
all users open it in multiple tabs and it's bad that session is
basically unusable in php 0_o
I wonder if they are going to fix it in php 6?

It's not just a PHP issue. It also has to do with Apache, the OS, and
HTTP protocol and the browser. As other languages have the same
"problem", I doubt it will be "fixed" because it's not broken.

And sessions are quite useful in PHP. I use them all the time, and so
do every PHP programmer I know. They just can't be used like you want
them to be used.

As I said - find another way to do it. For instance, use a database and
keep the key to the row in the session.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Sergei Shelukhin]

Huh? ASP.NET doesn't have this problem, and neither does ASP. As far
as I remember Perl doesn't have this problem either, I don't remember
how I stored the session back then tho. If for example I want to store
some token between several pages it's pretty impractical to do so in a
database, taking care of the timeout/cleanup and uniqueness code too,
the fact that there's a variable that either locks up parallel
requests or is readonly is pretty illogical from my fresh point of
view :)

The strangest thing is that the app I'm now maintaining and improving
was written by an actual PHP programmer who used session in this way
and somhow tricked users into believing that slow search query locking
up their profile editing is ok 0_o

[Jerry Stuckle]

Sergei Shelukhin wrote:

Huh? ASP.NET doesn't have this problem, and neither does ASP. As far
as I remember Perl doesn't have this problem either, I don't remember
how I stored the session back then tho. If for example I want to store
some token between several pages it's pretty impractical to do so in a
database, taking care of the timeout/cleanup and uniqueness code too,
the fact that there's a variable that either locks up parallel
requests or is readonly is pretty illogical from my fresh point of
view :)

The strangest thing is that the app I'm now maintaining and improving
was written by an actual PHP programmer who used session in this way
and somhow tricked users into believing that slow search query locking
up their profile editing is ok 0_o

Hmmm, you're right - ASP doesn't lock it. But then ASP has known
problems with session corruption when the session is being accessed by
multiple windows. I can only assume ASP.NET, if it works the same way,
has the same problem.

And IIRC, Perl also has a problem with multiple windows accessing the
same session. But the last time I had that problem was a while ago;
most of my new programming is in PHP nowadays. So perhaps that
"problem" has been fixed.

And you can store them in a database or you can store them in a file
(PHP's default).

Or, if you can't stand the way PHP handles sessions, you can, of course,
use a different language.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Sergei Shelukhin]

Umm, my last post was not intended for creating usual php vs asp
flame, but for clarification, ASP.NET doesn't have session corruption
problems for any storage mechanism available; for default in-proccess
session the session (but not auth) "goes away" if something like web
server restart happens, persistent storage doesn't have this problem
too. And I never knew of any session corruption problems in ASP 3.0
and never experienced it in my apps.

Then, I cannot use another language - I have to use PHP for this
project.

[Jerry Stuckle]

Sergei Shelukhin wrote:

Umm, my last post was not intended for creating usual php vs asp
flame, but for clarification, ASP.NET doesn't have session corruption
problems for any storage mechanism available; for default in-proccess
session the session (but not auth) "goes away" if something like web
server restart happens, persistent storage doesn't have this problem
too. And I never knew of any session corruption problems in ASP 3.0
and never experienced it in my apps.

Then, I cannot use another language - I have to use PHP for this
project.

I have seen session corruption in .ASP. It's timing related, but it
does happen.

And if you have to use PHP, then I suggest you stop complaining and get
to programming. This is how PHP works. You want it to work another
way? Use another language.

Much of it has to do with the fact PHP stores its session data on the
file system. Among other things, this can help by surviving a webserver
restart. But it also means only one thread can have the file open at a
time.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Sergei Shelukhin]

Well, I wonder if I could suggest a fix?
"But it also means only one thread can have the file open at a time."
- the solution for this is implied in one of the posts where I was
still unsure about how it works - a thread could open the file
exclusively, write to it, and then unlock it; reading could be done
without locking the file (if the file is currently locked then there
should be a reasonable/configurable timeout).

E.g. a standard reader-writer lock pattern.

[Jerry Stuckle]

Sergei Shelukhin wrote:

Well, I wonder if I could suggest a fix?
"But it also means only one thread can have the file open at a time."
- the solution for this is implied in one of the posts where I was
still unsure about how it works - a thread could open the file
exclusively, write to it, and then unlock it; reading could be done
without locking the file (if the file is currently locked then there
should be a reasonable/configurable timeout).

E.g. a standard reader-writer lock pattern.

By definition, if you open a session, you open it for both reading and
writing.

If you only want it open for reading, it's simple. Open the session,
cache the data you need then close the session.

Or use a different language. This is how PHP works. And you aren't
going to be able to change it.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================