Tim Peters wrote:
[Christian Heimes, suggests changing Transaction.commit() to start with

        if subtransaction:
            # TODO deprecate subtransactions
            self._subtransaction_savepoint = self.savepoint(1)

        if self._savepoint2index:

i.e. swapping the first two blocks]

[Jim Fulton]

subtransactions != savepoints

There is *no* promise of nestability with subtransactions. Committing a
subtransaction invalidates prior savepoints by design.  This is necessary
to maintain backward compatibility.

I'm not sure I follow this:  old code could not be using savepoints
directly, so what would break in code that stuck solely to subtxn commits?
> So I don't see how backward compatibility would be injured.  BTW, I tried
> it, and all the ZODB tests pass with this change.

When you so commit(1), the promise is that, if the top-level transaction
commits, then any work done up to the commit(1) is committed.  Consider
this scenario:

- new code: s = transaction.savepoint()
- old code: foo.x = 42
- old code: transaction.commit(1)
- new code: s.rollback()
- old code: transaction.commit()

Now, the old code expected that foo.x was 42.  It did a commit(1).
But, in fact, if we can roll back s, then in fact, the old code
can't count on the semantics of the commit(1).  This would be
a change in behavior for subtransactions.

Subtransactions only provide one level of nesting.  They are
not the same as savepoints.

Now, I don't know for sure that anyone depends on the non-nestedness
of subtransactions.  Mostly, subtransactions are used to checkpoint
incomplete changes to disk. So perhaps the backward compatibility
risk is small.


Jim Fulton           mailto:[EMAIL PROTECTED]       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org
For more information about ZODB, see the ZODB Wiki:

ZODB-Dev mailing list  -  ZODB-Dev@zope.org

Reply via email to