On Tue, 16 Aug 2005 11:48:36 -0400 (EDT), "mike bayer" <[EMAIL PROTECTED]> said: > - 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.
I don't think read/write locking for sessions is a Must Have, either. It's nice if it's easy to do (which it is, in a threaded situation), but fundamentally the session is not the right place for caching Lots Of Stuff. -Jonathan _______________________________________________ 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