On 19 May 2002, Jonathan Corbet said:
> I do wonder about the SessionManager.sessions variable.  Is there a reason
> for it to exist now that lookup_session is there?  In my setup, sessions
> (and the session namespace) can change behind the back of any individual
> server process, so caching things within any one process will not work.  I
> got around that by making "sessions" be a magic mapping that goes to the
> persistent store.  It seems I could get around that now - *if* "sessions"
> is not being used in other places.

Good point, and something like that occurred to me when I was writing
the DemoSessionManager class I posted.

First thought: assuming the standard SessionManager class continues to
be a simple, memory-only session collection, then yes *it* needs to have
a dictionary mapping session IDs to session objects.  But it doesn't
necessarily need to impose that implementation detail on subclasses that
store sessions some other way.

Second thought: for performance reasons, it's nice to have an in-memory
cache of session objects, even if they really live on disk somewhere.
But it should be up to subclasses to worry about that implementation
detail, *unless* there's an easy way for Quixote to make it available to
all subclasses without undue complication.

Third thought: in DemoSessionManager, the on-disk database of session
objects (one pickle file per session in a single directory -- why yes, I
do use ReiserFS ;-) and the in-memory dictionary of sessions seem to
cooperate perfectly well.  The only catch is that the in-memory
dictionary doesn't always list all sessions, because they are only
loaded on-demand -- so code that uses SessionManager's mapping methods
(keys(), values(), items()) won't actually see *all* sessions -- just
the ones that happen to be in the current server process's cache.

In summary, I haven't made up my mind yet.  I need to do some more
thinking and coding and see what falls out.  I'm reconciled to more
upheaval in session.py though, so what the heck.  Might as well get it
all done at once.

> For me, it was worthwhile to add an is_dirty() flag to the session object,
> and only flush it if something has changed - a relatively rare occurrence
> in my setup.

You must not have noticed Session.is_empty(), which is the same as your
is_dirty() only of the opposite sense:

    def is_empty (self):
        """is_empty() -> boolean

        Return false if this session contains any information that must
        be saved.
        """

BTW thank you -- I have been liking the name 'is_empty()' less and less,
but I couldn't think of what it *should* be called.  'is_dirty()' is the
obvious answer -- duh!

        Greg
--
Greg Ward - software developer                gward@mems-exchange.org
MEMS Exchange                            http://www.mems-exchange.org