Simple web application environments and per-request state

October 8, 2014

One of the big divides in web programming environments (which are somewhat broader than web frameworks) is between environments that only really have per-request state and every new request starts over with a blank slate and environments with state that persists from request to request. CGI is the archetype of per-request state, but PHP is also famous for it. Many more advanced web environments have potential or actual shared state; sometimes this an explicit feature of the environment over simpler ones.

(One example of a persistent state environment is Node and I'd expect the JVM to generally be another one.)

I have nothing in particular against environments with persistent state and sometimes they're clearly needed (or at least very useful) for doing powerful web applications. But I think it's clear that web environments without it are simpler to program and thus are easier to write simple web things in.

Put simply, in an environment with non-persistent state you can be sloppy. You can change things. You can leave things sitting around the global environment. You can be casual about cleaning up bits and pieces. And you know that anything you do will be wiped away at the end of the request and the next one will start from scratch. An environment with persistent state allows you to do some powerful things but you have to be more careful. It's very easy to 'leak' things into the persistent environment and to modify things in a way that unexpectedly changes later requests, and it can also be easy to literally leak memory or other resources that would have been automatically cleaned up in a per-request environment.

(At this point the pure functional programmers are smugly mentioning the evils of mutable state.)

Speaking from personal experience, keeping track of the state you're changing is hard and it's easy to do something you don't realize. DWiki started out running in a purely non-persistent environment; when I also started running it in a semi-persistent one I found any number of little surprises and things I was doing to myself. I suspect I'd find more if I ran it for a long time in a fully persistent environment.

As a side note, there are some relatively obvious overall advantages to building a web application that doesn't require persistent state even if the underlying web environment you're running in supports it. This may make it useful to at least test your application in an environment that explicitly lacks it, just to make sure that everything still works right.


Comments on this page:

By Jeremy at 2014-10-08 14:43:41:

In java, it kind of depends on the web framework you're using. You can of course access global variables (aka static variables) but only if you are deployed on a single jvm that doesn't shut down. That sort of thing is not recommended.

The servlet api provides explicit access to request, session and global scoped data. In theory, a servlet container can distribute an application across any number of jvms as long as it propagates the session and global state around.

Synchronization for concurrent requests within the same session is tricky. Afaik, modifications to session or global scoped data is immediately visible to requests being processed on the same machine, but changes would only be propagated between jvms at the end of each request. I don't think any explicit locking primitives are provided to prevent overwriting, but I haven't looked at this stuff in a long time.

As far as I understand, this is similar to php sessions, which may be serialized to disk and re-loaded when a new php interpreter is fired up, or even just between requests, in case there are more active sessions than can be kept in memory.

Written on 08 October 2014.
« Why blocking writes are a good Unix API (on pipes and elsewhere)
How /proc/slabinfo is not quite telling you what it looks like »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Wed Oct 8 00:41:09 2014
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.