diff options
author | Mike Bayer <mike_mp@zzzcomputing.com> | 2015-06-03 11:04:08 -0400 |
---|---|---|
committer | Mike Bayer <mike_mp@zzzcomputing.com> | 2015-06-03 11:04:08 -0400 |
commit | 16a87fe6d954def3143820217adf398d8eda42c9 (patch) | |
tree | d85d5e86c4b20a5ccc7423f2ec1a9a4502e75bc0 | |
parent | 5a17d73648dde740c2190b5d9006472ca7707320 (diff) | |
download | sqlalchemy-16a87fe6d954def3143820217adf398d8eda42c9.tar.gz |
- correctly categorize this changelog entry and rewrite it
to be understandable, now that there's some time past since
I first wrote it
-rw-r--r-- | doc/build/changelog/changelog_10.rst | 25 |
1 files changed, 10 insertions, 15 deletions
diff --git a/doc/build/changelog/changelog_10.rst b/doc/build/changelog/changelog_10.rst index 63f2c797f..68d809eaf 100644 --- a/doc/build/changelog/changelog_10.rst +++ b/doc/build/changelog/changelog_10.rst @@ -141,23 +141,18 @@ that will no longer work. .. change:: - :tags: bug, pool + :tags: bug, engine :tickets: 3419 - Fixed bug where in the case that a pool checkout event handler is used - and the database can no longer be connected towards, that the checkout - handler failure is caught, the attempt to re-acquire the connection - also raises an exception, but the underlying connection record - is not immediately re-checked in before the exception is propagated - outwards, having the effect that the checked-out record does not close - itself until the stack trace it's associated with is garbage collected, - preventing that record from being used for a new checkout until we - leave the scope of the stack trace. This can lead to confusion - in the specific case of when the number of current stack traces - in memory exceeds the number of connections the pool can return, - as the pool will instead begin to raise errors about no more checkouts - available, rather than attempting a connection again. The fix - applies a checkin of the record before re-raising. + Fixed bug involving the case when pool checkout event handlers are used + and connection attempts are made in the handler itself which fail, + the owning connection record would not be freed until the stack trace + of the connect error itself were freed. For the case where a test + pool of only a single connection were used, this means the pool would + be fully checked out until that stack trace were freed. This mostly + impacts very specific debugging scenarios and is unlikely to have been + noticable in any production application. The fix applies an + explicit checkin of the record before re-raising the caught exception. .. changelog:: |