[ZODB-Dev] Re: Savepoints are invalidated once they are used
Jim Fulton
jim at zope.com
Tue Jul 12 11:04:59 EDT 2005
Tim Peters wrote:
> [Christian Heimes, suggests changing Transaction.commit() to start with
>
> if subtransaction:
> # TODO deprecate subtransactions
> self._subtransaction_savepoint = self.savepoint(1)
> return
>
> if self._savepoint2index:
> self._invalidate_all_savepoints()
>
> 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
--
Jim Fulton mailto:jim at zope.com Python Powered!
CTO (540) 361-1714 http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
More information about the ZODB-Dev
mailing list