To Ward's first post: I think one may even doesn't need server cookie. Using a client-site cookie fits exactly the need.
Peter ----- Original Message ----- From: "Rob Nagler" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, June 13, 2002 7:49 PM Subject: Re: mod_perl/passing session information (MVC related, maybe...) > Perrin Harkins writes: > > My preferred design for this is to set one cookie that lasts forever and > > serves as a browser ID. > > I like this. It's clean and simple. In this sense, a browser is not > really a session. The only thing I don't like is garbage collection. > > > unique browser ID (or session ID, if you prefer to give out a new one > > each time someone comes to the site) lets you track this for > > unregistered users. > > We call this a visitor id. In the PetShop we have a cart id, but > we're not too happy with the abstraction. > > > I don't see that as a big deal. You'd have to delete lots of other data > > associated with a user too. Actually deleting a user is something I've > > never seen happen anywhere. > > We do. Especially when we went from free to fee. :-( The big issue I > have with "session data" is that it is often a BLOB which you can't > query. > > > Well, eToys handled more than 2.5 million pages per hour, but caching > > can be important for much smaller sites in some situations. > > I'd like numbers on "smaller" and "some". :) > > > Here's a situation where a small site could need caching: > > We cache, too. An interesting query is the "club count" on > bivio.com's home page. The count of clubs is a fast query, but the > count of the members is not (about 4 seconds). We compute a ratio > when the server starts of the members to clubs. We then run the club > count query and use the ratio to compute the member count. We restart > the servers nightly, so the ratio is computed once a day. > > > Maybe I just have bad luck, but I always seem to end up at companies > > where they give me requirements like these. > > It's the real world. Denormalization is necessary, but only after you > test the normal case. One of the reasons I got involved in this > discussion is that I saw a lot of messages about solutions and very > few with numbers identifying the problem. > > Rob > > >
