Posted by Josh Whiting on 03/12/05 22:50

On Fri, Mar 11, 2005 at 09:57:46AM -0800, Richard Lynch wrote:
> > well the trouble is not in the writing at the end of the request, which
> > would likely only be a single query and therefore not need a transaction
> > in itself. the trouble is the lack of locking out other requests from
> > reading the data when you're using it during the main body of
> > the request.
[...]
> Short Version: Either your frames/tabs are gonna be so clunky as to be
> useless, or you need to lock them into only one, or you need business
> logic, not session-logic. Solving the race condition at session layer
> will only make your application un-responsive.
>
> This may go a long way to explaining why you're not finding any readily
> available solutions out there at the session layer.

You raise good points. However, my goal is simply to have a
transparent, database-driven replacement for PHP's native session
handler. I don't want to change my application logic because I'm
switching session handlers - my application shouldn't care! And so,
transparently reproducing PHP's session layer functionality is going to
mean locking concurrent requests out, because that is what PHP's session
handler already does (for good reason IMHO).

you're argument about slow frames is valid, but is ALSO applicable to
PHP's native session handler, e.g. i'm not introducing a new problem.
the trouble can be mostly avoided in either case by not starting session
in frames that don't need it (most of them), and doing any session stuff
right away and calling session_write_close() ASAP to free up the lock so
other frames can run.

you're right that i could change my application logic to deal safely
with concurrent requests from the same session, but PHP already nicely
defeats the issue so you don't have to worry about it, and at a more or
less negligable performance loss if you design the scripts to reduce
session open/locked time to the bare minimum...

i would speculate that the reason i haven't found a readily available
solution is because most folks either (1) don't understand the problem,
or (2) don't think such a race condition is likely enough to warrant a
fix, or (3) are using a different backend (oracle, etc.) that makes the
problem easy to solve. the PHP team, however, clearly thought it was
important enough as is evident by their session handler design.

....have i convinced you yet of the worthiness of this endeavor? :)

/jw

[Back to original message]