Thanks for the input David - all excellent caveats to keep in mind.
Now let's see if the group can resolve some of the issues (jump in one and
all).
Taking items 1-4 to start with (not necessarily in that order though):
3. in general this can be handled OK if the site has an entry point
that performs authentication and then records the successful login in
the session. Any leap into the site behind this URL via a bookmark
will fail because the session will not exist or will not contain the
"successful login marker".
4. Actually I've no problem with multiple browsers with discrete sessions.
This is just another user - just like someone on another machine.
It's when they share the same session that problems can occur.
Note of course that the stateless nature does mean that you have to be much
more
careful with concurrency and locking on the persistence layer.
This is a very important topic that requires detailed understanding of the
application, RDBMS and data model.
1. I think this can be solved somewhat by setting the headers to expire the
pages and turn off caching. Of course we've all seen the million emails
expressing frustration at determining the exact sequence of headers needed
for each stupid browser.
2. This is the real pain.
The only thing I can say initially is that I do not think it appropriate to
encapsulate complete state in each page - a snapshot that rapidly becomes
out-of-date
if multiple windows are open and active.
All this does is make each page an atomic unit of work in isolation from a
broader
transactional context and also in isolation from what's actually happening
in the model
at the server.
I prefer to correlate actions with outcomes, implement outcome rules in the
workflow logic (aka state machine) and base the rule on the actual
persistent
outcome recorded at the server not at the client.
So in this example...
<David>
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.
</David>
... if user submits to Action4 from Pg 1 the state-machine will know that
the
outcome of Action 4 contradicts the current outcome of "State 3". How?
Well that's the design task specific to the application - no easy answer or
"one-size-fits-all" solution I think.
Another example...
<David>
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!
</David>
In this scenario you have a "race" condition.
If the P3 outcome is achieved first it should influence how the P4 logic is
performed.
As is the case with race conditions in threads you need to apply similar
rules of synchronization on the entities being manipulated - same locking
and concurrency problems alluded to earlier.
Anyway - I'm just throwing some pat responses up.
I'd love to see other input.
Thanks again David for raising some very real concerns...
Regards
@
===========================================================================
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
