Perrin Harkins writes: > I find you can tie this cache stuff up inside of your data access > objects and make it all transparent to the other code.
Absolutely. > A session is useful for very limited things, like remembering if this > user is logged in and linking him to a user_id. We store this information in the cookie. I don't see how it could be otherwise. It's the browser that maintains the "login" state. Consider the following scenario: * User logs in. * Site Admin decides to delete the user. * In our stateless servers, the user_id is invalidated immediately. * Next request from User, he's implicitly logged out, because the user_id is verified on every request. In the case of a session-based server, you have to delete the user and invalidate any sessions which the user owns. > Although Oracle can be fast, some data models and application > requirements make it hard to do live queries every time and still have > decent performance. This is especially true as traffic starts to > climb. I've tried to put numbers on some of this. I've never worked on a 1M/day site, so I don't know if this is the point where you need sessions. What sites other than etoys needs this type of session caching? Rob
