On Fri, 1 Dec 2000, Marc Krisjanous wrote:
> Hi all,
> I have an interesting question! Based on the scenario below what
> solutions could be provided?
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> The diaster scenario might take the form of an account manager
> opening up a customer's profile, ready to make a slight change in
> it. The manager remembers that another customer has similar values
> and proceeds to open up another, and simultaneous, browser window.
> This second window inherits the firsts cookie and hence client
> state. As far as the server is concerned, the singular browser
> instance just switched to a new customer profile. The manager views
> the second customer's information and then switches to the first
> browser window, makes some changes, and then submits them to the
> server. If the client state contained the primary key contained the
> primary key to the customer, the server might update the second
> customers record with the first customers data.
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Sounds like something in the design of your application assumes that
an account manager can only be looking at one customer profile at a
time. I don't see why it needs to be that way -- and in fact, you're
giving an example of why it shouldn't be restricted that way.
Of course, then there's the question of how you design things so that
the application doesn't have this restriction. Sounds like your
cookie and/or session data cannot be the only source of "client state"
info, that some of that info must be contained elsewhere, like in the
request and the response. I believe someone suggested using hidden
parameters as one way to carry the necessary client state info in the
response (and any resulting request).
This might just be another way of saying what Tim Panton said in his
response, I'm not exactly sure.
Milt Epstein
Research Programmer
Software/Systems Development Group
Computing and Communications Services Office (CCSO)
University of Illinois at Urbana-Champaign (UIUC)
[EMAIL PROTECTED]
___________________________________________________________________________
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
