I've tried to answer a few of these questions but one thing to keep in mind
is that app. server vendors are likely to implement this in different ways.
> I belive ive seen talk of a session object/layer. How does this
> work? non-persistent cookie? does it rely on this cookie 100%.
>
The session is a server-side chunk of server memory that is dedicated a
particular user's browser session. Typically it uses a non-persistant cookie
to maintain a browser's identity. Some vendors rely 100% on the cookie.
Others allow you to also use url rewriting that adds the "cookie" to each
URL. This does mean you'll need to programmatically handle this in your
code but its not that difficult.
> what about scaleability concerns? can this scale on a web farm easily and
> properly? (not redirecting user back to same machine in the farm - but
> being able to handle the request transparently across your entire
> farm). Basically, where is this session information stored? Server
memory
> where the session started, database or other shared storage medium on a
> per-user basis?
It uses server memory which means you don't want to store a few MBs of data
per user. For instance, storing large java.sql.Resultsets in the session
just so that the user can scroll through database records would be a bad
idea if you plan to have a lot of simultaneous users. There is a timeout
period that is set programmatically and/or by the server administrator to
determine when this thing will die if the user doesn't return to the site.
If you are using a server farm then this changes things a little. Again this
is vendor dependant but from what I've seen once a particular user has been
directed to a particular server in the cluster/farm then that user will
continue to interact with that particular server until they are finished
with the overall visit/transaction or until the server dies. Should the
server fail then various app. server vendors have different ways of
replication session information across the members of the cluster. In some
cases they use RMI to push session information to a backup server so that
when the user gets reconnected through the dispatcher/load balancer they'll
be attached to the backup server. In some cases they use the database to
persistent the session information so that each server knows to visit those
database records to see if the user has a session preestablished.
>
> How are the sessions identified? some sort of GUID? How is this
> generated, based on what criteria?
I'm not sure if there is a standard on this but from what I've seen the
cookie holds a GUID.
>
> What are the limitations of this? That is, if we start loading this up,
> how bad will it be for server performance? Anyone do any specific load
> testing?
Many of the major Internet websites use these types of technologies so it
seems that load can be handled.
Keep in mind that JSP is really just a Servlet and servlets can power very
big websites easily.
Burr
[EMAIL PROTECTED]
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
Some relevant FAQs on JSP/Servlets can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
