>I do have though, another question. Servlets are
>said to be multi user.
Whoever said that is being imprecise. Servlets are multithreaded.
They can service more than one connection simultaneously.
>I mean, what happens when a two users at the
>same time 'trigger' the servlet?
This has been explained many times on this list. If you check the
archives you'll find lots of interesting descriptions of what goes
on.
Basically when the servlet engine recieves a connection it creates a
thread to service the connection, the code of the thread establishes
which servlet the connection was intended to invoke and calls that
servlet's doPost() or doGet() method with the connection represented
as a request and response.
When the servlets's doPost() or doGet() method finishes the response
is sent to the browser (or whatever caused connection) and the thread
is destroyed.
>How do I handle the multi-task-ing? I'm reading the
>docs but as I recall the tutorial of j2ee (Duke's
>Bookstore) si using SingleThread model.
That is so annoying. If you search for SingleThreadModel on the
archives of this list you will find lots of explanation of why it is
evil.
It is really only included in the API to allow a completly safe
threading environment during development. You should *never* actually
use it for an application.
>This means that only one user can communicate
>with the servlet? What about the others in this case ?
When they load a servlet that implements STM most engines create a
pool of instances which they can then use to service multiple requests
simulataneously.
This is one reason that STM is evil, because most programmers don't
expect this behaviour and may not code their servlets appropriately.
It's easy to avoid the need for STM... you just have to think a bit
about threading.
>And how can I do track-session when the servlet
>is working with multiple users? Do I open a task for
>every request and make a session for it? Isn't that
>a resource-eater?
Session tracking is the technique used to tie a single user to some
data between requests. Recall that HTTP has no state and so techniques
like this have to be used. It's a simple matter of having a hashtable
of data keyed against unique identifiers. The unique identifiers,
called session ids, are sent to the browser in the form of a cookie.
The browser ensures that the cookie is sent back to the server so it's
possible to automatically retrieve the data associated with a session
id.
It's not a resource eater... no more than any other state crarrying
mechanism (like class variables for example).
Bear in mind that sessions are not really a mechanism for multi-user
apps. They do facilitate that but in fact you should understand that
they are really multi-client apps. It's the user's browser that is
tied to the server side data (the same user logging on from another
machine won't get the same session data).
Nic Ferrier
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
