Nicolas Lehuen wrote:
> 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.
Doesn't SQLite suffer from similar locking issues you'd encounter with a
pickle? Wouldn't the lack of concurrent write access cause problems on a
busy server?
Yes it does ! I'm trying to find the best transaction isolation level, but at the end of the day, SQLite locks the full file on commits, which is why it is ultimately less scalable than table-level or row-level locking DBMSes. But, this is the same problem for DBMSession (for which we had to handle locking by ourselves, remember !).
Regards,
Nicolas
