Re: Can a script run twice?

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