[Web-SIG] Web Container Interface
Phillip J. Eby
pje at telecommunity.com
Wed Jan 28 14:41:34 EST 2004
At 12:57 PM 1/28/04 -0600, Ian Bicking wrote:
>Currently Webware's primary session mechanism keeps the session in memory
>until the session reaches a certain age (likely because the user has gone
>away), at which time the session is pickled and moved to disk, in case the
>user comes back. This is done with a scheduling service that is part of
>Webware, as is the ultimate expiration (where the file is
>removed). Locking is handled with thread locks, because Webware expects a
>single-process model. Also, when the AppServer is shut down or restarted
>(which can happen very often during development), all sessions are pickled
>and written to disk.
So, it sounds like Webware would say that its services were only runnable
under single-process gateways. That sounds like a from-the-ground-up
architectural decision. It's not going to be runnable under CGI or
mod_python, certainly. But it *would* run in a single-process Python web
server, or using FastCGI either as a dynamic app with maxclass=1, or as an
"external" FastCGI app.
>So, there's an existing session mechanism. The exact details of the
>implementation don't have to be maintained, but the external interface and
>semantics should be. That involves:
>* Sessions that persist over multiple requests.
>* Sessions persist over server restarts.
>* Objects put into the session do not need to be stored in client-side
>* Some concurrency protection (applications still need to consider their
>own concurrency requirements).
>* Sessions are expired in a consistent, scheduled manner.
>Now, most of these can be implemented for CGI. The last one would
>probably be slightly different, in that there may or may not be a
>scheduling service -- cron job or otherwise -- so an ad hoc scheduler that
>runs whenever a session is fetched may be necessary. But the
>*implementation* would be significantly different depending on the
>context. Webware's currently implementation wouldn't work in CGI, and to
>determine an optimal implementation it has to know something about the
>environment it's being run in.
I understand where you're coming from, but the proposal isn't intended to
make fish into birds or vice versa. I'm pretty sure it was discussed
previously that applications that assume a particular process model are
only going to run in gateways that can provide that process model. That's
*still* more gateways than they can run in now!
>And, to make it a little harder, we've often had requests to implement
>memory-only sessions, to put unpickleable objects into the session.
>Usually we just tell people to keep these values in module globals. But
>module globals are also unportable across environments.
But if your framework only supports a "long running, single-process"
architecture, module globals would work just fine with any gateway that
Frankly, "multi-process only" and "short running" gateways are going to be
in the minority anyway. The only gateway I know of that's likely to
*require* multiple processes is mod_python, and the only gateway that's
likely to be "short running" is plain CGI. So, it's not like requiring an
"LR/SP" gateway is going to dramatically limit the choice of gateways for
Obviously, the PEP needs to have examples of these process models added,
and clarify the nature of the restrictions. Who knows, maybe if we talk
about this long enough maybe we'll be able to clarify the process models
well enough to define a variable that services can expose to indicate their
compatibility with various process models.
At that point, we almost might as well go ahead and make the API have all
five Java servlet methods, call the objects servlets, and be done with it. :)
More information about the Web-SIG