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 <[EMAIL PROTECTED]>:
Gregory (Grisha) Trubetskoy wrote:
> I think it might be interesting to see something like an ANSI SQL-92
> compatible session with some suggestions on how it can be easily
> integrated with your database vendor of choice, but deifinitely not
> support specific database vendors, except for those whose support exists
> natively in the Python distribution (which is none at this point).
>
>>> and is this the path we want to take, or is there something about
>>> sqlite that makes it unique?
>
>
> ...so nothing unique about sqlite? If so, I don't think it should be
> part of mod_python unless/until it is standard in Python, then we can
> discuss it.
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
