Basically, there are to kind of "session tracking" wether you use identified
or unidentified session. With unidentified session tracking, you pass the
data making the session back and forth between the client and the server.
When the client holds the session, the server does not know anything about
it. When the server hold the session, the client doesn't need to know
anything about it.
With identified session tracking, you just store the session data somewhere
and pass a session id back and forth between the client and the server. The
server is supposed to hold the session. So, there are two tasks to achieve :
storing the session and creating ids. Storing the session can be achieved in
different ways, depending of the degree of persistence needed for the
session : in memory, in a file, in a database, or whatever you want.
If, for any reason, you need to do your own identified session tracking, you
have to create unique ids. One relatively secure way to create unique ids is
to concatenate the address of the session object and the time at which it is
created, because no two objects can exist at the same address at the same
time. (If you need unique ids across different servers, just add the addess
of the server).
Java session tracking is just a convenient way of managing sessions, because
all the work is done automatically for you. It is an example of identified
session tracking, which is not always the most desirable solution.
Unidentified session tracking might be better if the data making the session
is small and must persist indefinitely, and if the number of clients is
potentially high. For example, if you consider a server playing chess with
an unlimited number of clients, it would probably be preferable to managed
the data (a list of moves) as rewrited URLs than to store it in a database,
as the session ID would be more data than the session itself.
Pierre-Yves
-----Message d'origine-----
De : A mailing list for discussion about Sun Microsystem's Java Servlet
API Technology. [mailto:[EMAIL PROTECTED]]De la part de
Christopher K. St. John
Envoyé : mercredi 4 avril 2001 16:49
À : [EMAIL PROTECTED]
Objet : Re: HttpSession id
Marjou Xavier wrote:
>
> I would like to create an HttpSession with my own
> String id.
>
You'll have to roll your own session handling if
you want to do that. There's probably a couple of
relevant threads in the archives.
What exactly is it you're trying to do?
> Why isn't it possible to create this object with for
> example: getSession(boolean create, String id) in
> HttpServletRequest,
>
I'll assume you know that session id's have to be
unique, and they might have other information (like
load-balancing info) coded into them. I'm guessing
that the spec-authors decided that exposing methods
to allow users to roll their own valid sesssion id's
made the api more complex while benefitting relatively
few, so they left them out. But I'm just guessing.
--
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com
___________________________________________________________________________
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
___________________________________________________________________________
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
