Commit 7be303d2 authored by Tim Peters's avatar Tim Peters

Merge rev 30284 from 3.4 branch.

Fixed some incorrect comments.
parent 29171512
...@@ -61,10 +61,10 @@ a weird traceback then ;-) ...@@ -61,10 +61,10 @@ a weird traceback then ;-)
One more, very obscure. It was the case that if the first action a new One more, very obscure. It was the case that if the first action a new
threaded transaction manager saw was a begin() call, then synchronizers threaded transaction manager saw was a begin() call, then synchronizers
registered after that in the same transaction weren't communicated to registered after that in the same transaction weren't communicated to
the Transaction object, and so the storage's afterCompletion() hook wasn't the Transaction object, and so the synchronizers' afterCompletion() hooks
called when the transaction commited. None of the test suites (ZODB's, weren't called when the transaction commited. None of the test suites
Zope 2.8's, or Zope3's) caught that, but apparently Zope3 takes this path (ZODB's, Zope 2.8's, or Zope3's) caught that, but apparently Zope3 takes this
at some point when serving pages. path at some point when serving pages.
>>> tm = transaction.ThreadTransactionManager() >>> tm = transaction.ThreadTransactionManager()
>>> st.sync_called = False >>> st.sync_called = False
...@@ -75,8 +75,8 @@ at some point when serving pages. ...@@ -75,8 +75,8 @@ at some point when serving pages.
>>> st.sync_called >>> st.sync_called
False False
Now ensure that st.afterCompletion() gets called by commit despite that the Now ensure that cn.afterCompletion() -> st.sync() gets called by commit
Connection registered after the transaction began: despite that the Connection registered after the transaction began:
>>> tm.commit() >>> tm.commit()
>>> st.sync_called >>> st.sync_called
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment