Cytat(Crozin @ 13.10.2012, 16:10:25 )

@kamil4u: Jeżeli chcesz wiedzieć jak dokładnie zachowa się serwer (w sensie maszyny, oraz w sensie serwera HTTP odbierającego żądanie) poczytaj sobie o wielowątkowości (sposobie jej realizacji na maszynach fizycznie nie mogących wykonywać kilku operacji na raz, jak i tych mogących takie rzeczy robić), a co za tym idzie i blokadach/synchronizacji (Google: concurrency lock/synchronization). Temat jest bardzo rozległy, nie ma sensu go tutaj w pełni opisywać (zresztą zapewne niewiele osób mogłoby tutaj się porządnie, merytorycznie wypowiedzieć). Gdy zgłębisz przynajmniej podstawy tej tematyki, część z Twoich wątpliwości rozwieje się sama.
W przypadku serwerów HTTP, można powiedzieć, że w przypadku gdy kilka żądań nadejdzie w niemal tym samym czasie, to które z nich zostanie zrealizowane jako pierwsze jest niemal niemożliwe do określenia (a właściwie to, którego realizacja zostanie zakończona jako pierwsza). Czym jest to spowodowane? Głównie architekturą takich serwerów, gdzie kolejność obsługi napływająch żądań nie ma większego znaczenia. Jeżeli interesuje Cię programowanie w środowisku, w którym liczą się dziesiętne części milisekund - Google:
low latency programming - ciekawy, lecz wymagający sporej dawki wiedzy teoretycznej temat; dla zdecydowanej większości z nas, kompletnie bezwartościowy.

Kilka wyjaśnień.
Low latency programming skupia się na wykonywaniu operacji szybko i tylko szybko. To znaczy nie jest gwarantowany czas wykonania - z prostego powodu - operacje zapewniające skończony horyzont obliczeń są kosztowne. Autora tutaj jednak interesuje gwarancja wykonania zadania.
Low latency programming jest przydatny przy HFT, gdzie brak odpowiedzi nie jest problemem. Przy systemie transakcyjnym musimy mieć gwarancję odpowiedzi (czasu już niekoniecznie). Są sytuacje gdzie potrzebujemy gwarancję odpowiedzi w danym czasie i tam techniki skracające obliczenia muszą być stosowane z ostrożnością, operacje muszą być przewidywalne (odpada Java i inne języki z GC) i wymogiem jest OS czasu rzeczywistego.
Wracając do problemu - wiele rzeczy możesz zrzucić na istniejące oprogramowanie, po pierwsze zaprojektuj dobrze skrypt i wykorzystaj bazę danych:
Kod
operacje...
rozpocznij transakcję db
pobierz flagę rejestracji
sprawdz czas
zapisz nową flagę transakcji jeśli dobry czas
zakończ transkajcę
operacje..
Dzięki temu masz gwarancję, że tylko jeden użytkownik może się ogłosić jako zwycięzca i zrobi to pierwszy, który otrzyma dostęp do bazy danych. To jest wszystko co możesz zrobić korzystając ze standardowych narzędzi, gdyż nie masz dostępu do synchronizacji pozostałych procesów na serwerze tj.
1. Gdy pętla odczyta wiadomość na porcie tcp musi przekazać sterowanie do serwera.
2. Gdy serwer dostanie informacje o żądaniu musi uruchomić (najpewniej) wątek środowiska skryptu
3. Zbudowanie środowiska i uruchomienie skryptu.
4. Wykonanie operacji przed rozpoczęciem transakcji.
O ile punkty 1 i 2 zależą od implementacji serwera możesz śmiało wnioskować o ich działaniu - zanalizuj kod. Są to działania jednowątkowe w ramach serwera (jak masz load balancer i dwa serwery to jest gorzej).
W momencie stworzenia wątku dla skryptu w grę wchodzi wielowątkowość i scheduler systemu operacyjnego. To znaczy może się uruchomić skrypt dla żądania pierwszego, wykonają się operacje... i wątek zostanie wywłaszczony na rzecz żądania drugiego, którego skrypt się wykona i otworzy transakcję do db. Mimo, że pierwsze żądania było pierwsze na serwerze to pierwszeństwo ma żądanie drugie.
Także nie jest może to "szczęście", ale wynik zależy w sposób nieprzewidywalny od stanu serwera w danej chwili. Na scheduler ma wpływ stan wewnętrzny serwera. Na moment wywłaszczenia wpływa czas wykonania skryptu, który (choć to ten sam skrypt) zależy od ... stanu wewnętrznego serwera. Połączenie z db i rozpoczęcie transakcji jest zależne od komunikacji sieciowej, która zależy od ... stanu wewnętrznego serwera oraz stanu połączenia. Więc chyba można nazwać szczęściem to, że kto będzie pierwszy może zależeć od tego czy admin właśnie włączył background joba, który odpytał zewnętrzny serwis i zapisał coś w dużej transakcji do bazy ...