Forgot to mention another bug in session cache: The _creation_time is updated to now every time the session is saved.
On Jan 7, 11:03 pm, Tycon <[email protected]> wrote: > Just to clarify, this fix is not really an "auto-save" like I > initially suggested. The fix is basically a "deferred-save", which > means that any calls to session.save() are not executed immediately, > and instead they are deferred to the end of the request. So if > session.save() is called at least once, the session will be saved at > the end of the request. > This means that there is no harm in calling session.save() multiple > times, so even existing applications that do that will now see an > improvement in performance without having to change the application. > This is on top of the other fixes that eliminate redundant loads > (before every save) and saves (after first access). > > On Jan 7, 10:39 pm, Tycon <[email protected]> wrote: > > > That's exactly what my fix does, it makes session.save() be deferred > > by setting a flag to perform the actual save at the end of the request > > in the session middleware. You still need to call session.save() at > > least once to make sure the session will be saved, so up upside of all > > this is that people don't need to modify their code to take advantage > > of this single deferred save design. And now you don't have to be > > afraid to add session.save() calls as they will not cause any > > unnecessary saves..... > > > On Jan 7, 10:25 pm, "Mike Orr" <[email protected]> wrote: > > > > On Wed, Jan 7, 2009 at 10:16 AM, Ben Bangert <[email protected]> wrote: > > > > On Jan 7, 2009, at 4:59 AM, Paweł Stradomski wrote: > > > > >> Just note, that in case the dict is not modified directly, but an > > > >> object > > > >> inside is modified, you won't get notified of the change. > > > > >> Eg. suppose the restored session has: > > > >> session['messages'] = [] > > > > >> Now i do: > > > >> session['messages'].append(u'New flash message') > > > > >> You won't see that the session has changed. > > > > > This is the exact reason we don't have a 'dirty' type flag like this > > > > set on > > > > setitem. However, I think it'd be useful to let a user set the 'dirty' > > > > flag > > > > themselves, in addition to letting sessions auto-save merely upon access > > > > (just to be sure), or something as Tycon suggests. Many people end up > > > > calling save() multiple times because they need to put stuff in the > > > > session > > > > in various places and ensures its saved, when really, they should be > > > > marking > > > > it 'to-be-saved' so its done just *once*. > > > > Ideally session.save() should really mean mark-to-save, and the actual > > > saving done at the end of the request. The issue is that a generic > > > function may modify the session (as is the case with Flash), and it > > > does not know whether the caller will call .save or not. Likewise, > > > the caller may not even know that the function is using the session. > > > > I do like the session.save() step because it acts like a transaction > > > commit, explicity confirming that the session is to be modified > > > persistently. On the other hand, it's not truly like a transaction > > > because there is only one session, and any call to .save() will cause > > > all changes to be saved, even if they were made in functions that did > > > not themselves call .save(). But in practice, nobody modifies the > > > session and leaves undesired changes in it counting on them being > > > rolled back, so it's more of a theoretical problem than an actual > > > problem. > > > > -- > > > Mike Orr <[email protected]> --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
