This module implements a transaction manager that can be used to define transaction handling in a request or view function. It is used by transaction control middleware and decorators.
The transaction manager can be in managed or in auto state. Auto state means the system is using a commit-on-save strategy (actually it’s more like commit-on-change). As soon as the .save() or .delete() (or related) methods are called, a commit is made.
Managed transactions don’t do those commits, but will need some kind of manual or implicit commits or rollbacks.
Acts as either a decorator, or a context manager. If it’s a decorator it takes a function and returns a wrapped function. If it’s a contextmanager it’s used with the with statement. In either event entering/exiting are called before and after, respectively, the function/block is executed.
autocommit, commit_on_success, and commit_manually contain the implementations of entering and exiting.
This exception is thrown when something bad happens with transaction management.
Decorator that activates manual transaction control. It just disables automatic transaction control and doesn’t do any commit/rollback of its own – it’s up to the user to call the commit and rollback functions themselves.
This decorator activates commit on response. This way, if the view function runs successfully, a commit is made; if the viewfunc produces an exception, a rollback is made. This is one of the most common ways to do transaction control in Web apps.
Enters transaction management for a running thread. It must be balanced with the appropriate leave_transaction_management call, since the actual state is managed as a stack.
The state and dirty flag are carried over from the surrounding block or from the settings, if there is no surrounding block (dirty is always false when no current block is running).
Returns True if the current transaction requires a commit for changes to happen.
Checks whether the transaction manager is in manual or in auto state.