Re: [PHP4BETA] Glahrrgh... Sessions...

On Fri, 26 May 2000, Boris Erdmann wrote:

> Daniel Gustafsson wrote:
> > 
> > How is the session data handled when using the PHP module? Are all the
> > registered variables stored in memory so that when one script changes it, a
> > concurrent script gets the new value when accessing it?
> > 
> > Let's say we have a frameset of three frames, all frames perform a check to
> > see whether a variable is set, if not, they perform some really heavy
> > functions to get it set. Using the "CGI" there's a fairly good chance that
> > all three scripts needs to set the variable (presuming the variables are
> > loaded at startup, and dumped at the end of the call). Is this the same
> > case with the module, or is it like a working application server?
> > 
> 
> What you describe, i assume, is the typical concurrency problem
> that many times has been reported to this list as "strange
> behaviour with sessions" when doing performance tests.
> 
> As i see it you cant control the behaviour of concurrently runnig
> scripts with the same session identifier (no locking mechanism
> provided) in php4. Thus you will always run into corrupted data
> using php4 sessions with frames - unfortunately.

Boris, your email was so full of ignorance that I had to delete the first
version of my reply.

Straight Facts:

First, there have been no reports about the "typical concurrency problem."

Second, it is right that you cannot control the concurrency behaviour
of sessions. We enforce the most strict protocol to ensure integrity
of data.

Third, the PHP session code itself will _never_ cause any corrupted
data, because we lock every file during a page request. That means
that at any given time there will be only one request which accesses
the underlying session storage object.

- Sascha