RelStorage for Sessions?

I’ve been working on a document explaining how to install Plone with RelStorage, starting from a basic Linux server.  As always, the basic procedure is simple, but there are all sorts of interesting little complications.  One detail that bugged me today is the need for a shared session database.

Session storage is a little different from normal storage because keeping a history of session state becomes expensive quickly.  For session storage, I think we still want all the goodness of ZODB transactions, conflict detection, distributed caching, and so on, but in this case, the ability to undo is pointless and the need to pack is a liability.

The database schema I’ve been using in RelStorage is a mismatch for this need.  A history-free storage should not have a “transaction” table, there should be no need for MD5 sums and prev_tid pointers, and the compound primary keys consisting of oid and tid should become simple primary keys indexed by oid.  A history-free storage still needs garbage collection, but not packing.

I’m thinking that the main RelStorage class will need few changes to support history-free storages, while the database adapter class will change so much that it would be best to just create a different adapter.  I like that.  It won’t be possible to switch history on and off without an export and import operation, but that seems reasonable.  To put a positive spin on the new adapters, I think I’ll call the new adapters “packless”, like the old BerkeleyDB storage.

I think that’s a good plan.  While the purpose of the packless adapters is initially session storage, they will certainly be also usable for other databases, including the main database.  I expect them to be slightly simpler and faster than the history-preserving adapters we have now.

I encourage anyone interested to leave a comment, even if all you wish to say is “I want that!” 🙂

9 thoughts on “RelStorage for Sessions?”

  1. I wonder if it would improve commit performance if multiple ZODB databases could live in the same RDBMS database and share the same RDBMS connections / transactions? If latency is bad I could imagine commits being slow otherwise.

Comments are closed.