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

-- 
Dossy Shiobara              | [EMAIL PROTECTED] | http://dossy.org/
Panoptic Computer Network   | http://panoptic.com/
  "He realized the fastest way to change is to laugh at your own
    folly -- then you can let go and quickly move on." (p. 70)


--
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.

Reply via email to