[Zope-ZEO] How do ZODB transactions work?

[Greg Ward]

I have yet to see any documentation of ZODB transactions with more
detail than this:

   get_transaction().commit()

I suspect this doesn't cover the full range of what's possible.  I
certainly *hope* there's more to it than that!  Specifically, we need to
know how sub-transactions work: how they are created, what the semantics
are, etc.

The context is this: we (currently) have a single-threaded web
application server with a single connection to a single database.  Most
of the data in that database is our domain objects, which *should* get
committed only after explicit user action and careful validation to
ensure consistency.  However, we also put session data in the database,
because we want it to persist across server restarts and this is a
convenient way to do so.  Also, most session objects keep a reference to
domain objects -- eg. if someone has logged in on a session, that
session keeps a ref to the corresponding User object.  So if we put the
sessions in the same ZODB as the domain objects, it Just Works.

However, sessions are committed frequently and implicitly -- typically
on every hit.  This means that we will commit possibly inconsistent
domain objects with every hit, because everything is going through that
sole Transaction object.

So I *think* the model we want is one transaction for the main server,
and one per session.  Session data would be committed via the main
server's transaction, and domain objects would be committed by the
session that made the change -- ie. if we're at a point where the user
has done some edits to something, has confirmed saving those edits to
the database, and our code has validated the affected objects for
consistency, then commit *just* the transaction for that session.

So:
  * does this sound like a sensible way of working?
  * can we make ZODB work this way, and if so, how?
  * is there a problem if database objects -- our persistent sessions,
    in this case -- have references to Transaction objects?  if
    so, can we work around this with __{get,set}state__() methods?

Thanks --

        Greg
-- 
Greg Ward - software developer                gward@mems-exchange.org
MEMS Exchange / CNRI                           voice: +1-703-262-5376
Reston, Virginia, USA                            fax: +1-703-262-5367