Just to be clear, there is a difference between "server state" and
"per-user state". The former is generally an order of magnitude or
three smaller than the later.
Let's consider the example of ebay. While not intimately familiar
with the details of ebay's architecture, I've read their whitepapers
(google "ebay scalability" if interested). Anyway...
There are two options -- probably more -- but two basic options if you
think about a paged ebay search result.
First option, traditional "servlet session" style state management.
User performs a search, that search result (or a reference to it) is
stored in the user's session, along with a "current page" or "current
item" indicator. When the user "pages" forward, their session state
is updated to reflect the current page their on. This has two big
implications. One, search results are unique to each user -- a
massive storage requirement for millions of simultaneous users. Two,
session state is frequently updated and because it's replicated for
failover is creates massive "back channel" chatter. Ebay *used* to
have this architecture. It crushed them and they had to re-architect.
Second option, recognize that users search for the same kinds of
things: "ipod nano", "macbook", "oakley". Store/cache search results
and share them between users. Use a URL parameter to determine what
page to show a user, rather than keeping track on the server of what
page they are on. Go to ebay and perform a search for "ipod", you'll
get a URL that looks like this:
http://shop.ebay.com/items/__ipod?...&_pgn=1
First tip they are using a cache is the __ipod in the URL. Second,
you can see the "paging" parameter on the end of the URL. If you go
to the next page of the result, _pgn will be 2.
Clearly, ebay is not "completely stateless". It has to store/cache
search results. However, these are not "per-user". Ebay is stateless
with respect to "user state". "Who you are" is handled by a cookie.
But if you look at your ebay cookies you'll see one called
"nonsession". :-) Maybe a joke on their part, but it reflects the
reality. Certainly you can maintain a hash of "nonsession" to true
user identity in the server. Maybe you would consider this "user
state", but I don't. There is a big difference between that kind of
state (to validate identity) and storing navigation position, history,
preferences, etc. in the server. Ebay jams about 15 cookies down your
throat so they don't have to keep that stuff in their memory or
replication it across servers.
Hope that clarifies the approach somewhat.
-Brett
On Jul 7, 4:46 am, ytrewqsm <
ytrew...@gmail.com> wrote:
> Thx brettt