Re: [ZODB-Dev] Re: Savepoints are invalidated once they are used
Tim Peters wrote: Bless you! Alas, I haven't received any messages from any Zope Corp checkin list since Sunday, so we'll just have to take your word for it . svn diff -r 33279:33280 \ svn+ssh://svn.zope.org/repos/main/Zope/branches/Zope-2_8-branch ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
RE: [ZODB-Dev] Re: Savepoints are invalidated once they are used
[Jim Fulton] >> A good community project would be to convert all of the subtransaction >> calls in Zope to savepoint calls. [Christian Heimes] > Done > > I found commit(1) in Zope3 zope.app.file.file Pdata handling and in code > and tests in Zope2. Bless you! Alas, I haven't received any messages from any Zope Corp checkin list since Sunday, so we'll just have to take your word for it . ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
RE: [ZODB-Dev] Re: Savepoints are invalidated once they are used
[Tim Peters] ... >> 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. [Jim Fulton] > 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. Right, _mixing_ the two can create surprises, and on both sides (for the new code too: since savepoints _do_ nest, I think it's at least as surprising for the author of the new code that calling old savepoint-free code could invalidate their savepoint). > Subtransactions only provide one level of nesting. They are not the same > as savepoints. More, savepoints are better (IMO). > 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. It would surely be a much happier outcome all around if ZODB users "simply" stopped using subtxns now. To set a good example, I think I'll take a bit of time today to rewrite the parts of ZODB that still use them (there is a little! at least one tool script and ExportImport.py). ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
Re: [ZODB-Dev] Re: Savepoints are invalidated once they are used
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:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
RE: [ZODB-Dev] Re: Savepoints are invalidated once they are used
[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? The internal savepoint used to implement commit(1) now isn't exposed to users, so they couldn't roll back directly to older subtxn commits, and the transaction internals only remember the (internal) savepoint for the most recent commit(1) done. So I don't see how backward compatibility would be injured. BTW, I tried it, and all the ZODB tests pass with this change. > If you don't like this behavior, don't use subtransactions. A good > community project would be to convert all of the subtransaction calls in > Zope to savepoint calls. Yup. Speaking of which, some of the comments say subtxns are deprecated, but they're not really. It's too late to deprecate them in 3.4 (for 3.6). Is it OK to deprecate them now in 3.5 (for 3.7)? I would like to, and deprecation nags are good motivators. If not 3.5, in 3.6 (for 3.8)? ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
Re: [ZODB-Dev] Re: Savepoints are invalidated once they are used
Christian Heimes wrote: Tim Peters wrote: ... Nesting savepoints works according to your test and I really believe you that they work in real live. Honestly! :) But there is some evil code in transaction/ that is destroying savepoints for my use case. Committing a subtransaction using the old and deprecated transaction.commit(1) syntax is invalidating all savepoints. The invalidation would be harmless but the zcatalog has a nasty feature. It is committing a subtransaction + GC cleanup after cataloging n object in a transaction. IIRC n=10,000 by default which might be reached much earlier than one can imagine. 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. If you don't like this behavior, don't use subtransactions. A good community project would be to convert all of the subtransaction calls in Zope to savepoint calls. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
