if I may throw my hat in the ring here, the session object I have built for Myghty accomplishes the following things, which were the important facets of a session for me:
- it is neutral of its backend storage system. I developed a simple "storage" API that currently has DBM, memory and plain file-based systems and people have also been clamoring for a memcached version which is easy enough to add. Myghty uses this backend containment system both for its page caching and session libraries. - the backend storage system supplies locking which locks amongst threads and processes; the session implementation insures that this lock is only against its own session ID. I was basically going for an improvement over mod_python's session, which locks all sessions against a single apache global mutex, and stores everyone's session in one huge DBM file. my session object, when using file-based containment, always keeps every session's information in separate files and was modeled after Apache::Session in this regard. - because a "read" operation also registers a "last accessed time" data member, its not using multiple reader/single writer style locking, everyone is a writer. However, since I am sensitive to iframes, ajax calls, and dynamic image calls hitting the same session concurrently within a request which I'd rather not slow down, I do something less than optimal which is I open the session store and read the full thing into memory first when its accessed, and then immediately unlock. This obviously can create problems for an application that is storing huge amounts of data in its session which is not required in full for any one request. Two improvements to this behavor would be to either make the "last accessed time" be written out just once per request and then to allow multiple readers, or to improve the containment API to supply "last accessed time" automatically. I mostly was using Apache::Session as a guide to the architectural features I wanted to see, which include flexibility of containment and locking systems as well as a separation between individual sessions. - mike _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com