Mukul Gandhi wrote:
> Hi,
> The lines below which Craig has written seem to be quite important to
> understand. But here I have a confusion. Say in doGet() method I write a
> statement creating a session object [ HttpSession session =
> request.getSession(true) ]. Lets assume sessions are managed using
> persistent cookies.
>
In other words, the servlet engine will set a particular cookie name to a value
equalling the session identifier of this user's session, and send it back with
the response.
>
> Now lets say a particular user has invoked a servlet from a particular
> client PC. Now that user's session is maintained by a cookie set by the
> servlet on his PC. Lets now say the same user on the same PC invokes the
> servlet again(either simultaneously or after some time lag). This another
> request by the same user would overwrite the cookie on his PC. Or does here
> the cookie is created new for another request by the same client ?
>
You can read the Cookie specs (RFC 2109 I think) for more details, but what will
happen is that your browser will send the session ID cookie along with any
request to the same host (and, with most 2.1-based apps, to the same
application). It does not matter which window sends it (although the browsers
vary somewhat in their behavior here), and it does not matter whether you are
going back to the same servlet or a different servlet.
The servlet engine will see that the session ID was already included in the
request. When the user calls:
HttpSession session = request.getSession(true);
this time, the old session object will be returned (insetead of creating a new
one). This is how information can be maintained across multiple requests -- the
same session object will always be returned, until that session is invalidated.
>
> I think it could be a different cookie. If its a different cookie then the
> same person is operating two sessions, otherwise there is only one session
> for that user.
> If there are seperate cookies for two invocations by the same client PC,
> then by identifying that cookie in servlet we could run different code for
> the same client. Otherwise, if cookie is same(i.e overwritten) for two
> different invocations from the same PC, everytime a new session is supposed
> to be created.
> Can somebody please clarify these concepts ? Specially synchronisation
> issue involved here(in relation to cookies & also using url rewriting
> mechanism).
>
>From the servlet author's point of view, there isn't much difference between
cookie-maintained and URL-rewrite-maintained session identitiy, except for the
case where a user might have more than one window open to the same application
at the same time. In that case, some browsers send the same session ID for both
windows (and the server thus thinks they are part of the same session), but they
will be considered distinct sessions if URL rewriting is used.
Reminder -- even if there is only one window, or you are using URL rewritijng to
have distinct sessions no matter what, you *still* need to be aware that
simultaneous requests are possible. Consider the following scenario:
* User submits a form to do a database search
that will take a while.
* That request starts running.
* User presses STOP because they do not want
to wait, and then issues a different request
to the application (say, they go back to the
main menu)
* This second request starts running, at the same
time that the database search is still running --
the servlet engine has no idea that the user
pressed STOP.
It may or may not make any difference, depending on your application design, but
you need to be aware that it's possible.
>
> -mukul
>
Craig
___________________________________________________________________________
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
