Hi all,

I'm sorry to have launched such a heated discussion. I was experimenting
with a SQLite implementation of sessions, and got something functional
enough that I wanted to archive it so that we could come back to it later...
.
I don't want it to distract us from the 3.2 release .

That being said, why SQLite ? Because it's simple to install and use (no
administration required). You just give it a file name and you're ready to
roll. Plus, I really wanted to experiment with SQLite .

I must confess that the current implementation seems 30% slower than
FileSession, but we are not cluttering the filesystem (due to FS clusters,
FileSession files all use a lot of disk space) and cleaning up old sessions
is very fast (I used a DELETE FROM sessions WHERE ... just like Jim
described), contrary to FileSession, so there is a tradeoff.

Better performance could be achieved if we could use a connection pool.
Unfortunately SQLite explicitely forbids about creating a connection in a
thread and using it in another thread (http://www.sqlite.org/faq.html#q8).
This means that the only connection pooling we can do is to associate a
connection to a thread (maybe using a thread local). I'll give it a try
later. Anyway, other DBMS clients usually don't have this particular
limitation.

As for a ANSI SQL-92 implementation, why not, but experience shows that ANSI
SQL-92 only takes you so far. See the excellent article on
http://troels.arvin.dk/db/rdbms/. This is complicated by discrepancies in
the various DBAPI implementations which feature different ways of passing
parameters (as of today I still don't understand why DBAPI allows for 4
different ways of passing parameters instead of only 1), escaping quotes,
etc. If you have a look at SQLiteSession.py, you'll see that's it's very
straightforward. Paradoxically, if you try to implement a generic
SQLSession, you'll have a much more complicated code. I think it'll be
easier to implement a Session subclass per DBMS.

Regards,
Nicolas


2005/9/23, Jim Gallacher <jg.lists@sympatico.ca>:
>
> Gregory (Grisha) Trubetskoy wrote:
> 
>
> Thinking about the session code, there is at least one big advantage to
> any SQL backend. One of the bottlenecks in both DbmSession and
> FileSession is in the expired session cleanup code.
>
> In DbmSession the cleanup code must iterate over *all* of the dbm
> records and unpickle each one to determine if the session data should be
> deleted. Needless to say this does not scale at all.
>
> FileSession is better or at least when the cleanup code runs it won't
> DOS the server. Again, we must iterate over all the session files to
> determine which ones have expired and should be deleted. I think I put
> some fairly clever things in there to make it scale, but I know it's not
> ideal.
>
> Contrast this with the cleanup for a SQL backend which would be as easy
> as:
> DELETE FROM sessions WHERE expires < current_time - timeout;
> assuming the sessions table has the expires and timeout fields updated
> from the session data when the db record is updated (or inserted).
>
> Thus a SQL backend would scale in a way that DbmSession or FileSession
> cannot. Granted, this is not unique to sqlite, but it is an argument for
> have some kind of sql session class.
>
> Regards,
> Jim
>

[ Post a follow-up to this message ]