#17887: postgresql_psycopg2 sometimes leaves connections "idle in transaction"
-------------------------------------+-------------------------------------
Reporter: brodie | Owner: nobody
Type: Bug | Status: new
Component: Database layer | Version: 1.3
(models, ORM) | Resolution:
Severity: Normal | Triage Stage: Accepted
Keywords: psycopg2 | Needs documentation: 0
transactions | Patch needs improvement: 0
Has patch: 0 | UI/UX: 0
Needs tests: 0 |
Easy pickings: 0 |
-------------------------------------+-------------------------------------
Comment (by akaariai):
I have been thinking that an "explicit transactions only" mode would be
very useful for debugging. This innocent looking code:
{{{
@commit_on_succeess
def myjob():
for obj in SomeModel.objects.all():
obj.xyzzy = SomeOtherModel.objects.filter(foo=obj.bar).count()
obj.save()
}}}
can result in idle-in-tx. Why? As I found out if you have a database
router making `SomeOtherModel` target a different database you have just
opened a transaction to the other db, and commit_on_success only handles
the default db. The point is, it is hard to know which transactions are
opened as side-effects. It would have helped me a lot if there was an
"explicit transactions only" setting. The `SomeOtherModel`.objects... call
would have resulted in error: "Need to open an implicit transaction to db
"other", but only explicit transactions allowed.".
In general, the transaction handling works pretty well in request handling
situations, somewhat well in single-db batch processing, and is hard to
use in multidb batch job processing.
I think in addition some more decorators would be welcome,
@close_connections would be useful (this is similar to what is done at the
end of request processing - all open connections are closed
unconditionally). @atomic (open a new transaction if there isn't one
already, create a savepoint otherwise) could be very useful, too.
There is a lot of work to do to make our transaction handling nice. The
implicit transactions are a source of idle-in-tx errors, and here some
debugging tools would be needed at least. In addition there are some
strange oddities. My favorite is that when you are running outside managed
transaction and try to commit or rollback you will get an exception
telling you that this transaction isn't managed. However, the
commit/rollback is done first, and only after that the exception is
raised, so you get the action done and an exception.
Maybe some design discussions on django-developers would be needed here...
--
Ticket URL: <https://code.djangoproject.com/ticket/17887#comment:4>
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 post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en.
