whatever you end up doing NEVER EVER DO a flush_all on memcached. Memcached is a global system service, it is not your private scratch pad.
On Dec 30, 8:22 pm, Michael Bayer <[email protected]> wrote: > On Dec 30, 6:09 pm, Tycon <[email protected]> wrote: > > > > > Let me clarify that using memcached in beaker doesn't work ONLY FOR > > STORING SESSIONS. > > > It does work for regular caching in beaker (e.g. using @beaker_cache > > decorator > > to cache controller actions etc). > > > This is not a bug, it's basically an incorrect implementation, which > > uses wrong design and is completely untested. For storing sessions in > > mecached you need to do the same thing as when storing session in a > > file - pickle the session and store it as a single key in memcached. > > So you can update or remove the session object in a single mecached > > call, and all the sessions attributes will have the same expiration. > > Storing each session attribute as a separate record is incorrect > > because memcached doesn't allow you to update/iterate/delete groups of > > records together. > > I'd like to add that the current incorrect memcached/Session > implementation is preferable to the previous implementation, in that > it fails immediately. The old version *would* appear to work since it > would store an additional element in memcached which consisted of all > the keys for a particular namespace, thereby allowing namespace.keys() > to work. But if the cache started pruning its data, then you'd get > random holes in your session data, or perhaps the list of keys() would > be pruned causing a similar failure to the one you have...but only > after many hours/days of uptime. > > That the file-based storage stores the session as a pickled dictionary > is an implementation detail of that backend. So once the Session is > modified to be appropriate against memcached, it would store a single > key in a session-id corresponding namespace, containing the session > dictionary (the Python memcached API does the pickling for us). Its > important that the namespace name is associated with the session id, > as opposed to using a constant namespace for all sessions - since in > file-based land, the namespace corresponds to a single file, and it > wouldn't perform very well to have all user sessions stored in a > single giant file with a single pickled dict inside. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
