On Wed, Oct 15, 2008 at 1:55 PM, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > By the way, for something like sessions, the scaling solution is not to > use server-side storage at all for the session data. Typically sessions > don't actually hold that much data and even in cases like, say, a > checkout trolley, you could push the data into a session-correlated > table, rather than the session object itself. > > So client-side sessions (signed cookies, etc) are the way to go in that > case.
Session-correlated table? Though you talked about session, I guess you were addressing my concern about user messages. User messages should probably ideally go to cookies, even if message can be long, they expire after only one request, so there is little cookie overhead. Session based messages[1] will also solve the same problem. So if we use non db SessionStorageEngine and Session based messages, we can live with SELECT only for GET requests. My wish for django would be, either 1. a position that other than the Session, there is no data changes by entire django if request method is GET. or 2. a wiki/doc page explaining what all database changes that can happen as part of GET request processing by django, and a suitable workaround [hoping a workaround exists for all use cases, currently the workaround for user messages is only available as a patch attached to a ticket]. Some kind of clarity on this would be good to have for 1.x. [1]: http://code.djangoproject.com/ticket/4604 -- Amit Upadhyay Vakow! www.vakow.com +91-9820-295-512 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
