durusmail: quixote-users: SQL-based session persistence techniques.
SQL-based session persistence techniques.
2004-02-22
2004-02-29
2004-03-01
2004-03-05
2004-03-18
SQL-based session persistence techniques.
Titus Brown
2004-02-22
Hi, all.

I'm currently working on a new (straight SQL-)based session persistence
mechanism for several packages, to replace an old, somewhat broken, and
overly-complex O/R-mapping-based session persistence mechanism that I've
been using.

So, I spent some time reading through session.py (which hasn't really
changed between 0.6 and 0.7a3, it seems) and trying to figure out the
best place to override the default functions for persistence.

My current SQL implementation overrides the session_mapping parameter
during the SessionManager instantiation:

        SessionManager.__init__(self, MySessionObj, SqlTableMap(db_conn))

where 'SqlTableMap' mediates between the dictionary and the SQL table and
MySessionObj is a subclass of session.Session (the default Quixote session
class).

There are two reasons why this is an imperfect approach:

  * I haven't figured out how to deal with transactions, so for the
        moment I'm committing each time a change is made to the mapping.
        My problem here is that I haven't yet grokked the implications of
        combining a single database with multiple SCGI server processes.

  * Loading sessions from the SQL database is a pain, unless I completely
        re-implement the session.Session class.  The pain is because
        session.Session takes an HTTPRequest object, which I cannot
        construct easily.  (Right now I'm faking it with an object that
        implements the get_environ function, which is all the Session
        constructor needs.)

I think with a bit of thought I can figure out how to deal with transactions,
but I'm hitting a fair amount of cognitive turbulence with regards to the
session object.  I could simply override SessionManager.new_session, copy
the Session code into a new class in my own app, and then use that for
a session object.  A cleaner approach, IMO, would be to change the Quixote
'Session' object in several ways:

* have the constructor take the remote address directly as an argument, and
        remove the 'request' object as an argument;

* have the constructor take the creation_time and access_times as optional
        arguments (or provide an accessor function to *set* the creation
        time) and only call time() if they are not provided.

So, the session.Session class constructor would look like this:

    def __init__ (self, id, remote_addr, creation_time = None):
        self.id = id
        self.user = None
        self.__remote_address = remote_addr
        if creation_time is None:
           self.__creation_time = time()
        self.__access_time = time()
        self._form_tokens = [] # queue

and SessionManager.new_session would just call

        self.session_class(id, request.get_environ('REMOTE_ADDR'))

to create a new session class.  When session classes are loaded
from the database, the creation time could be set via the constructor;
right now it's not possible (without deprecated Python judo) to set
__attributes directly.

Thoughts?  Comments?

cheers,
--titus


reply