Re: State Wars, part XI (was: Revised Charter)

M. Hedlund:
>[Lou Montulli:]
>>In fact, [Dave's proposal] reduces the capibilities such that it is nearly
>>unusable for large scale applications such as online shopping.
>
>I disagree (as a programmer for an online shopping site).  I do agree that
>an extremely large online shopping site with many stores or large ordering
>possibilities might hit an upper limit with the state-info proposal if they
>tried to store all ordering info in the State-info: header.  This concern,
>however, is not pressing for the vast majority of ordering systems, which
>accumulate a small number of items in each session.

I agree.

>  I would like to see
>the State-info proposal incorporate the cookie proposal's concept of
>"path", which I think would solve this problem.

"path" may shift the upper limit to a higher value (but only if
implemented in a certain way), but it will not solve the problem of
there being an upper limit (determined by the browser, server, and
proxy software) on the size of the State-Info header transmitted.

If your amount of state is larger than the upper limit, you will end
up storing it in a server side database, using the contents of the
State-Info header as a key into the database.

Of course, this is not elegant.  A server cannot generally detect the
end of a session, so it will have to use some timeout scheme to take
no longer used key-state pairs out of the database after, say, 12
hours.

The question is: is this solution to the large shopping bag problem
feasible?  I think the answer is yes.  The resource requirements for
this database solution are not higher than those of several things we
already have:

1) Size of the database:

- The database will always be very much smaller than the server access
  log file, so that is not a problem.

2) Time spent doing database lookups:

- WWW servers already do (cached) database lookups for each request:
  they map the IP address of the client to its internet host name for
  use in the logfile.  Session state database lookups will have the
  same time complexity and opportunities for caching.

- WWW servers that use authentication also do database lookups for
  each request:
    - www.dds.nl has a database of 30,000 username/password
      combinations accessed for each request.

3) Time spent implementing the database

- It was very easy to implement cached database lookups with timeouts 
  in my Futplex system.

- If such databases turn out to be used often, I expect that either
  someone will write a library, or that this functionality will become
  a standard part of WWW servers.

>M. Hedlund <hedlund@best.com>

Koen.

Received on Friday, 3 November 1995 06:46:03 UTC