summaryrefslogtreecommitdiff
path: root/lib/sqlalchemy/testing/engines.py
diff options
context:
space:
mode:
authorMike Bayer <mike_mp@zzzcomputing.com>2014-01-12 19:43:13 -0500
committerMike Bayer <mike_mp@zzzcomputing.com>2014-01-12 19:43:13 -0500
commit9c64607572a04eb2ed7981db8999732100f39d4d (patch)
tree111f47a4d93fcd1c86800d16b9797b2f991d7caa /lib/sqlalchemy/testing/engines.py
parentc91fd822bc9816827d0aab4699e304ab49ed8280 (diff)
downloadsqlalchemy-9c64607572a04eb2ed7981db8999732100f39d4d.tar.gz
- :class:`.Connection` now associates a new
:class:`.RootTransaction` or :class:`.TwoPhaseTransaction` with its immediate :class:`._ConnectionFairy` as a "reset handler" for the span of that transaction, which takes over the task of calling commit() or rollback() for the "reset on return" behavior of :class:`.Pool` if the transaction was not otherwise completed. This resolves the issue that a picky transaction like that of MySQL two-phase will be properly closed out when the connection is closed without an explicit rollback or commit (e.g. no longer raises "XAER_RMFAIL" in this case - note this only shows up in logging as the exception is not propagated within pool reset). This issue would arise e.g. when using an orm :class:`.Session` with ``twophase`` set, and then :meth:`.Session.close` is called without an explicit rollback or commit. The change also has the effect that you will now see an explicit "ROLLBACK" in the logs when using a :class:`.Session` object in non-autocommit mode regardless of how that session was discarded. Thanks to Jeff Dairiki and Laurence Rowe for isolating the issue here. [ticket:2907]
Diffstat (limited to 'lib/sqlalchemy/testing/engines.py')
0 files changed, 0 insertions, 0 deletions