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

Reply via email to