<rafiee.nima@gmail.com> wrote:
>suppose there are 3 airline counter which fill ticket forms and send
Three users... You may not think of them as users, but each
"counter" needs some identification (cookie or whatever) to let the
server track their transactions.
>them to the cashier maybe simultaneously .forms are sent to the
>cashier which is just a function in my view ,,I want to know how I can
>handle these simultaneous request ..I also should be concern about
One invocation of your view will only see one request from one user.
The only way multiples would be processed in parallel is if the server
can start multiple copies of the view (another reason for something like
a cookie -- so all data relevant to the view copy can be tagged in the
database, and retrieved later by another view invocation from the same
session). I don't know enough about the web-server side -- Django's
development server is probably single-threaded [check the Django
documentation] so only one request (first to arrive) will be processed
completely and only when it sends its response will the next request
(which will be backed up in the TCP/IP input buffers) be handled. On a
production server, there may be either /n/-copies of the application
running in a wait state -- so when a request comes in, the server can
dispatch it to an idle process immediately OR the server spawns a new
copy of the application whenever a request comes in (the old CGI
scheme), this process exits at the end of the request. In either case,
it is the server controlling whether a request is handled immediately
(able to spawn a new process or pass it to a pre-existing idle process)
or back-logged (partly by how many "connections" the server will accept
at one time).
>power failure ( actually It is important not to miss queued request
>if there is any queue )
That's what uninterruptible power supplies, backup generators, and
multiple distributed servers are for... <G>
But as for the requests, how do you expect the browser end to tell
the difference between a slow transaction (back-log at the server) and a
lost transaction (server failed). If you code a time-out in the browser
end (Javascript) and resend the data, you will again need a cookie or
something to identify the session /and the packet/ -- so that you don't
process the same transaction multiple times in the case of a slow server
-- the server will have to match the cookie/id to some database and
determine "this has been seen already, reject it"
You'll want a journaling database/filesystem to allow for recovery
from power-down of the drives. TCP/IP connections should, at the
low-level, ensure that if a packet was sent by one end, it has been
received and acknowledged by the other end... But if you also have to be
concerned about the data being lost between acknowledgement and commit
to database you are again going to have to code your own transaction
protocol on top of TCP/IP (at least you don't have to worry about
bit/byte-packing in an HDLC protocol, but you may want to study the
protocol for ideas on ensuring packets are processed). You may actually
have to embed much of the application logic using AJAX to ensure the
client can respond to slow/lost processing without having to restart
from an empty form.
--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com HTTP://wlfraed.home.netcom.com/
--
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to django-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
No comments:
Post a Comment