#19707: TransactionMiddleware leaks transaction state
-------------------------------------+-------------------------------------
Reporter: akaariai | Owner: nobody
Type: Bug | Status: closed
Component: Database layer | Version: 1.4
(models, ORM) | Resolution: fixed
Severity: Release blocker | Triage Stage: Accepted
Keywords: | Needs documentation: 0
Has patch: 0 | Patch needs improvement: 1
Needs tests: 0 | UI/UX: 0
Easy pickings: 0 |
-------------------------------------+-------------------------------------
Comment (by carljm):
I haven't spent as much time looking at this as you have, Anssi, but it
seems to me that catching the case in the signal handler where
`abort()`/`close()` raise an error is outside the reasonable scope of what
Django can handle, and that it would be safer to just allow that error to
raise normally and force the developer to deal with that condition, as
before. If an error was raised in abort/close, there's no particular
reason to think that removing our reference to the connection will
actually close it successfully, so the current approach seems to me quite
likely to leave connections hanging open (just as it is doing in the tests
you mention).
--
Ticket URL: <https://code.djangoproject.com/ticket/19707#comment:10>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
