At 12:38 PM -0400 5/24/06, Robert Cummings wrote:
On Wed, 2006-05-24 at 09:44, tedd wrote:
-snip-
> Back to the posters problem, which is duplicate dB entries caused by
double clicking.
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?
No the problem with ajax and sessions is usually scripts not releasing
the session as soon as they are done. In which case an ajax request
blocks all other requests with the same session. For instance I have
ajax requests that hit the webserver for slow feed requests that can
take up to 10 seconds. If I didn't manually close out the session, then
all other requests with the same session (either from browser or other
ajax requests) would block for about 10 seconds.
If ajax requests are seeing race conditions related to sessions then it
is usually due to a custom session implementation that doesn't perform
locking.
Cheers,
Rob.
Rob:
I wasn't addressing ajax. But considering the question has been
raised -- the race problem is not limited to, or caused by, sessions
and appears to be further complicated by browsers.
Please note the following relevant excerpts taken from the following link:
http://swik.net/Ajax/Ajax-Development-Gotchas
Multiple Ajax Requests are not fired in order.
IE, breaking from a long tradition of ignoring independent standards,
chooses to follow the HTTP 1.1 RFC 2616 to the letter, which means
that IE may only have two XMLHttpRequests open at a time; after which
IE will retain an internal queue of requests which will be serviced
in no particular order. Even if the requests are fired in order, the
nature of the internet dictates that they will not be received in
order, so never write code that assumes XMLHttpRequests will be sent
in a particular order.
Firefox also has a similar albeit more liberal limitation in the
number of simultaneous XMLHttpRequests that may be open; however in
Firefox 1.5, the developer may modify the priority of the internal
request queue.
Asynchronous XMLHttpRequests responses will arrive in no particular order.
As implied by the word Asynchronous, XMLHttpRequest responses may
arrive at any time in an unpredictable order that is ignorant of
developer intent, happily executing callbacks in the random order in
which they eventually wind up on the client.
Synchronous XMLHttpRequests lock up Firefox.
The XMLHttpRequest method provides a third argument, which defines
whether the Ajax requests are submitted synchronously or
asynchronously. (xmlhttprequest.open('GET',
'http://www.mozilla.org/', false);) On Firefox, setting this value to
false will submit the xmlhttprequest synchronously and lock up the
entire browser for the duration of the request.
And so on...
So, ajax exhibits concerns beyond sessions.
tedd
--
------------------------------------------------------------------------------------
http://sperling.com http://ancientstones.com http://earthstones.com
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
