On Tue, 2006-05-23 at 17:26, Paul Novitski wrote:
> At 01:50 PM 5/23/2006, Lester Caine wrote:
> >>2) the script that processes input, which redirects to:
> >
> >Yep that is the one, and it does check if the user already has an
> >existing ticket, but it does not see the ticket created by the first
> >click of double click in Moz :(
> >*THAT* should prevent the second record !
> >
> >>3) the page that displays the results (or is the next form in a sequence).
> >
> >This just sees the second record and not the first :(
> >
> >>Even if the user reloads the results page (3) they won't be
> >>resubmitting the form (1) or repeating the input processing (2).
> >
> >Exactly what should be happening. The bit I have to work out is why
> >the second page is not seeing the already loaded ticket! Which I
> >think is exactly where I started, the scripts seem to be processed
> >in parallel and so do not see the data committed by each the other instance.
>
>
> I really don't see how this could be browser-dependent. (Unless you
> have cookies or session cookies disabled in your Mozilla browser?)
>
> I can see that, in theory, it might be possible to submit a form
> twice in succession so quickly that the first query is still being
> processed by PHP when the second query is initiated. It's hard to
> imagine such a slow database or script, but perhaps all it would take
> would be a slow internet connection.
>
> However, if you flag form submission in the session cookie I don't
> think it's practically possible to slip a duplicate by. Because both
> form submissions would exist in the same session context, the server
> would know that a tenth or hundredth of a second previously the same
> session had submitted the same form, and could squelch it.
These are called race conditions for a reason. They are racing against
all kinds of things. Network latency, filesystem, processor, etc etc.
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
Cheers,
Rob.
--
.------------------------------------------------------------.
| InterJinn Application Framework - http://www.interjinn.com |
:------------------------------------------------------------:
| An application and templating framework for PHP. Boasting |
| a powerful, scalable system for accessing system services |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for |
| creating re-usable components quickly and easily. |
`------------------------------------------------------------'
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
