Lester Caine wrote:
The double click 'problem' was a sideline to the original problem, which
I found while trying to track things. The original problem *IS* that PHP
can run two copies of a script in parallel and the second copy does NOT
see the 'locking' in place on the first copy. I had always thought that
PHP was sequential, but I'm not so sure now.
I've put in a trap for the double click ( and yes it *IS* browser
dependent ) and that works fine, but we will have to see if it makes any
difference to the original 'race' problem :(
PHP is not 'sequential' and I have no idea where you got that
impression. If the browser puts in a request to the server, the server
will execute that request as soon as sufficient resources are free to do
so. PHP does not 'lock' the session between requests. This is a problem
being found by people trying AJAX with a session. Consider this sequence...
1) User hits your button (ooh-err)
2) PHP starts processing the script and runs session_start() which loads
the session data
3) User hits your button again
4) PHP starts processing the script a second time before the first run
has finished, and loads the session data again for this new request
5) The execution started in 2) ends and commits the session data back to
the session store
6) The execution started in 4) ends and commits the session data back to
the session store
There are 2 different issues here. First is that the second run will not
get any changes made in the first run. Second is that any changes made
in the first run will be lost when the second run commits the session to
the store. This is a fact of the stateless nature of HTTP and you need
to plumb around it. There are various ways you can do this. I'm the
first to admit that I haven't found an ideal solution yet, but methods
I've used in the past have been...
* Before start_session() check a directory for the existence of a file
named after the session id. If it doesn't exist call start_session() and
touch the lock file. Delete the lock file at the end of the request
(ideally using register_shutdown_function).
* Use shared memory to store an array of session ids that are locked.
Neither of these were ideal because there was a race condition where two
requests could check the lock at the same time and then both lock it.
Now that I come to think about it again it may be possible to write a
custom session handler that blocks reading of session data that's been
locked until it's either unlocked or a timeout passes. You'd have to try
that to see if it's possible - I'm not sure how the internals of
session_start() work.
Hope that early morning ramble helps you out.
-Stut
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
