Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make MailDataManager more lenient about when abort may be called #35

Open
wants to merge 7 commits into
base: master
Choose a base branch
from

Conversation

dairiki
Copy link
Contributor

@dairiki dairiki commented Jun 30, 2015

The checks that MailDataManager.abort and .tcp_abort perform regarding when in the transaction life-cycle they may be called are too strict. They raise exceptions during certain scenarios involving failed commits. When that happens those exceptions replace/mask the underlying exception responsible for the commit failure, which make troubleshooting difficult.

This fixes that.

Additionally, the last commit in this series (7225040), moves the sending of email from tcp_finish to tcp_vote. Justifications for this:

  • The transaction docs state that tpc_finish “should never fail”.
  • When a tcp_finish does raise an exception, transaction logs a critical error, preceded by the comment “do we need to make this warning stronger?”.
  • That’s the way does it (for non-two-phase sessions.)

Edited to fix the link to "the last commit in this series". (2015-06-30)

Commit (send) email from tpc_vote rather than tpc_finish.  The
documentation for ``transaction`` says that tpc_finish should never
fail.  Data managers which really have only "one-phase-commit" semantics
(and whose commit operation may fail) should do the deed in
tpc_vote.  (At least, that's what zope.sqlalchemy does.)

Refs:
  https://zodb.readthedocs.org/en/latest/transactions.html#tpc-finish
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant