mike at perusion.com
Fri Apr 10 14:13:50 UTC 2009
Quoting Ethan Rowe (ethan at endpoint.com):
> I'm trying to understand why this "servlet" idea is particularly
> relevant to the Ajax discussion that started the whole thread. I think
> what it's coming down to is:
> * Ajax-heavy applications are typically characterized by relatively
> infrequent "big" requests alongside very frequent "little" requests
> * Those "little" requests may be in response to user-generated events or
> timer-based events, and consequently have concurrency patterns that are
> potentially more complex than we're traditionally used to seeing
> * The heavy-weight, exclusively-locked sessions don't lend themselves
> well to concurrent (or near-concurrent), frequent little requests
> It seems that you (Mike) have concerns about IC being a heavy-weight
> process beyond just the session itself.
Absolutely. Even throwing hardware at something doesn't solve the
problem, because then you have the pain of coordinating sessions.
> > No, I haven't determined that at all. In fact, I have a couple of
> > 200,000 visitor sites that easily run on one not-so-beefy server. But
> > the optimizations aren't there in a standardized way. If you use
> > mv_tmp_session you have no security, and if you use sessions you have no
> > optimization. We use mv_tmp_session along with Autoload and custom
> > cookie settings for our optimizations, but it is a hack all the way.
> Here's a suggestion: refactor the session-handling in Interchange such that:
> * a base session model class defines the interface for anything that can
> act as a "session"
> * provide separate session-type modules that implement that interface
> (possibly via subclassing, but it doesn't really matter for purposes of
> this discussion) for different storage schemes. Storage schemes to
> - standard file-based sessions
> - database (DBI) sessions
> - cookie-based sessions (meaning the session state is serialized into a
> - etc.
> * remove session initialization/fetching/locking from the main dispatch
> * instead, always access sessions through either an object method, a
> class method, or a simple function, and the act of accessing the session
> is what first initializes/fetches the session
That isn't practical for IC as it stands right now. Too much session-based
code using direct access. That is IC 6.0 or son-of-Interchange stuff.
I think we can figure other ways to make a decision as to whether to
use the heavy session. When we get into a UserTag, for example. We
provide a parameter
which indicates that code won't access session values not in a cookie.
Otherwise we trigger session fetch/lock at that time.
If we want to do ITL interpretation for templates that use only the
lightweight session stuff, then we have a interpolate_light routine
that doesn't use session-based info (or fakes it).
> * do not attempt to lock a session until the application attempts to
> change a value in that session (though that behavior could be
> configurable, of course; some session types might be better off with
> delayed locking, while others might be better off with exclusive,
> immediate locking, depending on the application and purpose)
> * introduce session names, such that a given name corresponds to a
> session instance of a particular type. This would allow segregation of
> application/session state to different session types/instances.
> For an Ajax-heavy application, you might want:
> * the "default" session to be cookie-based and to hold little other than
> user authentication data, on average, though there's no reason it
> couldn't hold the shopping cart data as well, allowing for client-side
> cart manipulation
> * a "checkout" session that is file or DB backed, that uses standard
> locking and such
> Only the checkout-specific pages/actions would use the checkout session.
I am not sure I like the "checkout" name, I think I would call it a
"page" session, implying that the lightweight sessions are pointed toward
In the usual IC configurable fashion, I would think we would allow
sets of information to be defined that stayed in the cookie.
SessionCookie values fname 2weeks
SessionCookie values lname 2weeks
SessionCookie carts main 8weeks
SessionCookie session host 0
SessionCookie session tables 0
SessionCookie session logged_in 0
We structure the config data so it provides a routine-ready table for
the expiration setting of the cookie.
> So only the checkout process incurs the heavier cost of DBI sessions,
> locking, and so on. All other processes are lightweight, with no
> locking, no fetching of external resources for session state, etc.
My idea was to do a simple read-only one-row database session, but a cookie-
based session could be much the same. It should be valid from a security
standpoint if we check it against a valid heavyweight session's
existance and a hashed secret. If we can provide a mechanism to vary the
expiration date of individual members, we could even keep the shopping
cart around longer to provide a solution for that frequent request
(meaning carts that last weeks/months).
Perusion -- Expert Interchange Consulting http://www.perusion.com/
phone +1.765.328.4479 <mike at perusion.com>
Find the grain of truth in criticism, chew it, and swallow
it. -- anonymous
More information about the interchange-users