Using a multithreaded web server?

[Akihiro Matsukawa]

I believe most web servers / frameworks are all multithreaded in order to concurrently handle multiple requests. Doesn't this theoretically make it very difficult for us to implement this auction service with absolute 100% accuracy? There is no guarantee that the web server will finish processing requests that are received first, but the auction service depends on it. 

For example, isn't it possible that I as a client send auction_start, then bid with the correct parameters very quickly (but sequentially). The server receives the requests and start processing them in 2 threads. Technically, there is nothing wrong with the requests that I sent. But isn't it possible for the server to finish processing my bid request and before my auction_start request, giving me the incorrect result (eg. it'll ignore the bid when it shouldn't).

Do we have to worry about this? 

[Akihiro Matsukawa]

(Of course this is very unlikely with low load and enough time between requests, and the server will work fine 99.9% of the time...)

[Peter Alvaro]

> very quickly (but sequentially).

without waiting for a response from the first post?  perhaps.  but the unit test scripts wait for post responses.  your server should NOT return responses before it has updated state.  

not sure what framework you are using, but if your web server is multithreaded, you probably need some synchronization anyway to safely update the server state in the event of concurrent posts.  right?

[Akihiro Matsukawa]

Ah, ok so we can assume clients won't send a new request until it receives the response from the previous one. 

I'm using flask.py, and yeah, using locks. But python locks don't guarantee that threads acquire locks in the order they called acquire(), so it didn't solve the problem above. 

Thanks!

[Peter Alvaro]

> we can assume clients won't send a new request until it receives the response from the previous one. 

at the very least, you may assume that clients will not expect a GET to return state updated by a POST until receiving a response for that POST :)