[Zope-ZEO] How do ZODB transactions work?

[Jim Fulton]

Greg Ward wrote:
> 
> I have yet to see any documentation of ZODB transactions with more
> detail than this:
> 
>    get_transaction().commit()

Have you looked at the transaction management documentation at 
http://www.zope.org/Documentation/Developer/Models/ZODB/?

There's also some discussion of the role of transactions, 
sub-transactions, and versions at:

http://www.zope.org/Members/jim/Info/IPC8/ZODB3

> 
> 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.

This is discussed in the UML model above. You can also find an example
of their use in the Zope Image and File objects. 
 
> 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?

Sub-transactions aren't really intended for this. They are
intended to provide a way to checkpoint progress in memory
or cpu-intensive transactions. I think that
versions are a much better approach. Versions are meant to 
capture work, typically spread over a relatively long period,
requiring human interventon.

Jim

--
Jim Fulton           mailto:jim@digicool.com   Python Powered!        
Technical Director   (888) 344-4332            http://www.python.org  
Digital Creations    http://www.digicool.com   http://www.zope.org    

Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email
address may not be added to any commercial mail list with out my
permission.  Violation of my privacy with advertising or SPAM will
result in a suit for a MINIMUM of $500 damages/incident, $1500 for
repeats.