> For a start, sure HTTP is a stateless protocol but almost all web
> *applications* involve the maintenance of some form of
> <semantic>state</semantic>. Isn't that what the session object is all
about?
> Moreover, there is invariably a persistence layer e.g. RDBMS behind all
> this.
This is absolutely true, and is in fact the way that traditional stateless
systems, like banking ATMs, etc. work in the online transaction processing
world. State can be maintained in a session object, but be careful and do a
few calculations to determine how much data will be stored in the object
(the objects themselves and all objects they point to) and then how many
concurrent sessions you'll need to support. The scale of the web can be
scary if you are successful <smile>
Anyway, much state is kept in a database since this helps solve problems
like web servers going down, load balancers causing a subsequent request to
go to another web server, or the person simply went to lunch and then
continued working where "they left off," which generally means a new session
has to be created because very few people have sessions that last longer
than 30 minutes. Recall that a longer session life makes it "easier on the
programmer," but it does mean a lot more state left in memory (session
objects) because you not only have to deal with concurrent users, but all
users who come into your system over a 30 minute interval. Even after the
visitor leaves (unless they were so kind as to click on a logoff button or
the like), you won't know it and the data won't be available for GC until 30
minutes pass (i.e. whatever your session timeout value is).
The problem or difficulty on the web is that users will receive zero
training on using a web site. It must be obvious to them how to use it, and
you'll have to handle all the fun things users can do:
1) Users can click BACK and FORWARD as many times as they want.
2) Users can have multiple browser windows open at the same time while
visiting your site (very easily by holding the SHIFT key when click on an
URL or doing an "open in a new window" right click). All these windows
generally share the same session/cookies.
3) Users can enter URLs directly or from a favorites/bookmarks and jump,
either to another place on your site or they can just leave your site.
4) Nasty, but they could even be running two separate browsers, and each
would be considered a separate session with separate cookies.
Trying to track state in these cases can be much more tricky since the
"state" you think the user is in is not necessarily what they have on their
screen. It's nearly impossible (perhaps it IS impossible) to know when a
user does any of the above things that will cause them to see pages that you
won't know about.
i.e. User goes from Page1 -> Page2 -> Page3. Your state machine thinks the
user is in "state 3." User clicks back twice. They are on Page1 but your
state machine doesn't know it. They click something from Page1 taking them
to Page4. You need to be able to handle that, even if Page1->Page4 is
legal, but Page3->Page4 is not.
Or, user goes to Page1. Shift clicks to get to Page2. Two windows are
open. User clicks from Page1 to Page3 in one window, and from Page2 to
Page4 in the other window. What "state" is the user in? The same user is
on two pages at the same time!
But, you obviously can create a state machine and track the state in session
objects or use their logon id as a link to persistent data. This is the way
to go. Just be careful if you think you can control the flow of a user's
experience on the web. The tools don't work that way. Whenever possible,
make sure the "state flows" are identified by having some piece of
information passed along in URLs and be prepared to handle state transitions
of all sorts.
So, the best bet is to remain as flexible and stateless as possible,
ensuring each page contains enough information to determine WHERE they are
coming from and WHERE they are going...
David
===========================================================================
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
