Robert Cummings wrote:
Apparently the problem isn't solvable by using tokens, sessions,
locking, and such. So why not just check the dB to see if the current
record has already been entered? If so, don't do it again.
Isn't this a solution? Or is there something here that I'm
not understanding?
...or maybe do a 'REPLACE...' rather than an 'INSERT...'? That way the
record is not entered into the database twice if it already exists. Might
be a more economical way than doing a "lookup/compare/write if" sequence.
JM
I didn't suggest using either. I just said check first before adding
a duplicate record.
However, using REPLACE rather than INSERT would probably be best. The
MySQL manual states that REPLACE works exactly like INSERT except
REPLACE either inserts, or deletes and inserts. So, it's still a
"lookup/compare/write if" sequence, but it's an internal mysql
operation, which should be quicker and less coding (i.e., more
economical) than using php/mysql to do it.
This stuff presumes you have an ID upon which to replace. What about
task/bug type submissions where the entry is created upon submission
with it's own unique key?
And I don't use anything as unreliable as MySQL to generate the ID's
(check sig) ;)
I have already indicated that my problem was caused by NOT updating the
_SESSION soon enough. Having added that, then the second 'run' simply
kicks out because the the 'browser' is already flagged as serving. The
delay caused by accessing the ID to use for the next record allowed the
second 'run' to start a second request. So initially I've set the ID to
-1 and used that as a 'busy' flag, until firebird returns the real one,
which as solved most of the problems.
I just had not appreciated that the second 'run' would start when the
first was waiting for the database response. When things are on the same
machine, the response is fast, but looking to a separate database server
allows a bigger window which the second 'run' slipped into hence the
differences between sites.
The double click action on Moz allowed me to track exactly what was
going on, but a simple _SESSION[ID] = -1 solved the problem :)
There is still a possibility that the second 'run' will beat the first
run, but in that case I would expect the first one to be scrapped instead ;)
--
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
