So are you saying that on a multi-page form, where you fill in one form, the
next page/form "depends" on the previous entries, and so on until you get to
the LAST page where the "transaction" is finalized, data is stored, etc and
a thank you page is brought up. In this scenario, EACH page/form is a
separate "action"?
>-----Original Message-----
>From: A mailing list about Java Server Pages specification and reference
>[mailto:[EMAIL PROTECTED]]On Behalf Of Andrew S Tomlinson
>Sent: Friday, May 05, 2000 3:42 PM
>To: [EMAIL PROTECTED]
>Subject: Re: Web Apps and state machines (was: model 2 servlet mapping
>question)
>
>
>RE: Concurrency
>I agree that each "page action" is by necessity a discrete transaction.
>
>The issue is a standard multi-user problem - in the absence of a
>stateful locking scheme is the data I am writing consistent with
>what I read
>?
>There are many approaches:
>- re-read the record and compare each data item
>- use timestamps on access
>- track the keys of accessed items
>-differentiate between operations that are obviously read-only versus r/w
>etc.
>Developers should be cognizant of all these issues and not take the
>"hand-grenade" strategy or rely on low synchronicity.
>As you commented - the key is to validate what you are doing at
>the back-end
>in each operation.
>
>RE: browser paradigm (back/forward)
>
>Well, you are correct in stating that the developer must handle these
>actions.
>They won't go away by wishing it so...
>I contend however that the reason we use the browser is not because of its
>modeless paradigm but rather because of its ubiquity.
>Deployment was the curse of application delivery - media costs,
>installation,
>config, support desks etc.
>There's no denying that the look&feel defacto standards that users are now
>familiar
>with have dramatically reduced/eliminated the "learning curve" but
>I'd wager
>that
>no-one using their on-line banking/trading would miss the back/forward
>buttons if
>they simply weren't there.
>The "browser" has become an application delivery platform and should mature
>as such.
>
>"Wizards" work back/forward because the "back/forward" operations are
>submitted to the
>server for processing. Browsers don't work because they take over and just
>resort to the
>cache which we know is implemented horribly and inconsistently.
>
>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
>
===========================================================================
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
