Skip to content
Projects
Groups
Snippets
Help
Loading...
Help
Support
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in / Register
Toggle navigation
Z
ZODB
Project overview
Project overview
Details
Activity
Releases
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Issues
0
Issues
0
List
Boards
Labels
Milestones
Merge Requests
0
Merge Requests
0
CI / CD
CI / CD
Pipelines
Jobs
Schedules
Analytics
Analytics
CI / CD
Repository
Value Stream
Wiki
Wiki
Snippets
Snippets
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Create a new issue
Jobs
Commits
Issue Boards
Open sidebar
Kirill Smelkov
ZODB
Commits
f66e9a3d
Commit
f66e9a3d
authored
May 06, 2005
by
Tim Peters
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
Merge rev 30284 from 3.4 branch.
Fixed some incorrect comments.
parent
11a9a4c2
Changes
1
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
with
6 additions
and
6 deletions
+6
-6
src/ZODB/tests/synchronizers.txt
src/ZODB/tests/synchronizers.txt
+6
-6
No files found.
src/ZODB/tests/synchronizers.txt
View file @
f66e9a3d
...
...
@@ -61,10 +61,10 @@ a weird traceback then ;-)
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
registered after that in the same transaction weren't communicated to
the Transaction object, and so the s
torage's afterCompletion() hook wasn't
called when the transaction commited. None of the test suites (ZODB's,
Zope 2.8's, or Zope3's) caught that, but apparently Zope3 takes this path
at some point when serving pages.
the Transaction object, and so the s
ynchronizers' afterCompletion() hooks
weren't called when the transaction commited. None of the test suites
(ZODB's, Zope 2.8's, or Zope3's) caught that, but apparently Zope3 takes this
path
at some point when serving pages.
>>> tm = transaction.ThreadTransactionManager()
>>> st.sync_called = False
...
...
@@ -75,8 +75,8 @@ at some point when serving pages.
>>> st.sync_called
False
Now ensure that
st.afterCompletion() gets called by commit despite that the
Connection registered after the transaction began:
Now ensure that
cn.afterCompletion() -> st.sync() gets called by commit
despite that the
Connection registered after the transaction began:
>>> tm.commit()
>>> st.sync_called
...
...
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment