Robert Cummings wrote:
These are called race conditions for a reason. They are racing against
all kinds of things. Network latency, filesystem, processor, etc etc.
One site has take down it's Cisco backbone and replaced it with simple
hubs. Problems disappeared overnight! ( That was not just my problems )
Any one of these thigns can slow down one thread just long enough for a
newer thread to grab the session data before the older thread saves it.
Then the newer thread happily uses the stale session and voila duplicate
input. If you absolutely, definitely, for sure want to prevent this...
use some kind of locking mechanism. I'd suggest locking the table that
manages the form submission unique IDs until you've checked and, if
necessary, updated it. There's a reason pages load sequentially in
multiple frames when using PHP sessions... it's because PHP uses
locking. Are you using PHP native sessions or your own home cooked
system? Are sessions even activated? Did the user disabled sessions? Why
am I teaching you second year comp sci? :)
http://en.wikipedia.org/wiki/Race_condition
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 :(
--
Lester Caine - G8HFL
-----------------------------
L.S.Caine Electronic Services - http://home.lsces.co.uk
Model Engineers Digital Workshop -
http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/
Treasurer - Firebird Foundation Inc. - http://www.firebirdsql.org/index.php
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
