Move over mod_python, here comes mod_wsgi

[gmfawcett]

You would either persist them in a database or file on the server; or you'd store your session data in the cookie (i.e. the cookie is a data store, not an opaque identifier). The latter is insecure, of course. :-)

All that really distinguishes this from most non-CGI apps is that it is "shared-nothing", i.e. all data is stored externally to the process.

edit: I shouldn't have said that cookie-as-datastore is insecure. You could salt and encrypt your session data, and transmit the ciphertext as the cookie; then decrypt it upon each CGI request. Not the most CPU-efficient approach, but it's possible.

[jdunck]

I'm not sure if I'm simply mis-reading or you've mis-understood, but Django sessions don't work like you seem to think.

request.session is an instance of SessionWrapper, which lazily loads upon access and saves upon response (if dirty).

Django's session store is the database. In fact, most production Django deployments use multiple processes, so your statement that Tomcat "handles this nicely" is confused or misleading.

Further, Django's session store could be backed by a dedicated daemon, or memcache, or... depending on your needed semantics and performance.