Dossy, The problem described is exactly what ns_cond solves. But what is the problem?
Executing code withing a mutex lock which takes meaningful time. Instead with ns_cond, you use a mutex just so you can grab a condition variable, or at least try to grab it, and if not go to sleep and wait. Once you are woken up, you still have to try again to grab the condition var. But both mutex and sema will spin and use up cpu. John: there is a way to setup threadpools in AOLserver to limit the number of threads executing a page. But this still doesn't seem to be what your problem is here. The double submit problem has been around for a long time and I came up with a one page solution: on submit you make a signature of the variables using a hash of the unique inputs. Record the hash. Check if the hash is unique, abort if not. I stored the hash in a db, but it could easily go into an nsv if you are only worried about close-in-time uniqueness. This also allows users to back up and make small changes to input and resubmit. If the data is going into the database, usually the critical factor is that you don't get duplicate data, if the server is overloaded or not it seems like the mutex solution might not solve the uniqueness problem every time. tom jackson On Friday 23 February 2007 05:54, Dossy Shiobara wrote: > On 2007.02.23, John Buckman <[EMAIL PROTECTED]> wrote: > > I'm trying to block the "double submit" problem on web pages, where a > > page submit takes too long (because something else is taking up the > > server), so the user hits cancel and resubmits. > > > > When the original taking-up-the-server code completes, now the two > > submissions occur at exactly the same moment, and the submission is > > processed twice. I currently use a database (check the database to > > make sure this operation hasn't previously run) call to prevent this, > > but if the two pages occur at the exact same moment, the database > > call isn't atomic enough to prevent the double-submit. > > What you really want is a condvar or semaphore, so yeah, I'd look at > ns_cond or ns_sema. Before you start the "work" you'd "sema down" ... > since only one thread can have the semaphore at a time, all the others > will sleep. When that thread finishes, it must "sema up" and that'll > wake up one other thread that has "sema down'ed" and is currently > sleeping. > > > Instead, to solve the "double submit" problem, I planned a more > > simple strategy: > > 1) try to grab a mutex, so I'm the only one doing this > > 2) if I can't grab a mutex, wait 1 second, and try again > > 3) after 5 seconds, give up on the mutex, and proceed anyway, since > > if there is a double-submit, chances are the two threads aren't > > running at the same moment any more. And, display an error, so that > > the programmer can investigate and see if there is a deadlock-causing > > bug in this code. > > Mmm, yeah, the whole "desire a timeout" urge is the problem, as I think > "ns_sema wait" doesn't allow you to specify a timeout, either. > > So, the question becomes: is it better to add "-timeout time" to all the > blocking subcommands, or to add "ns_mutex trylock"? In theory, > "-timeout 0" should perform the trylock equivalent. > > -- Dossy -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
