Database connection management when using only Django ORM

Question

I am using Django ORM layer outside of Django. The project is a web application using a cusotm in-house built framework.

Now, I had no problems to set up Django ORM to run standalone, but I am a little bit worried about connection management. I have read Using only DB part of Django here at SO and it is true that Django does some special connection handling at the beginning and the end of each request. From django/db/__init__.py:

# Register an event that closes the database connection
# when a Django request is finished.
def close_connection(**kwargs):
    for conn in connections.all():
        conn.close()
signals.request_finished.connect(close_connection)

# Register an event that resets connection.queries
# when a Django request is started.
def reset_queries(**kwargs):
    for conn in connections.all():
        conn.queries = []
signals.request_started.connect(reset_queries)

# Register an event that rolls back the connections
# when a Django request has an exception.
def _rollback_on_exception(**kwargs):
    from django.db import transaction
    for conn in connections:
        try:
            transaction.rollback_unless_managed(using=conn)
        except DatabaseError:
            pass
signals.got_request_exception.connect(_rollback_on_exception)

What problems can I run into if I skip this connection management? (I have no way to plug in those signals into my framework easily)

Connection management problems; the kinds the code you pasted handles for you. — Burhan Khalid, Jan 23 '12 at 13:47
@burhan What I mean is, is it safe to skip this code? I know some guys use Django ORM as standalone and they probably skip this code, I wonder is it working correctly. — pajton, Jan 23 '12 at 13:53

score 1 · Answer 1 · answered Jan 23 '12 at 14:21

It depends on your use case. Each of these functions do something specific, which may or may not affect you.

If this is a long-running process and you have DEBUG on, you'll need to reset the queries or it'll keep all the queries you've run in memory.

If you spawn lots of threads, connect to the DB once early on in each thread, and then leave the threads running, you'll also want to close the connections when you're done using the DB, or you could hit your DB's connection limit.

You almost certainly don't need _rollback_on_exception - I'm assuming you have your intended transaction behavior set up within the relevant code itself.

I'll keep in mind to turn DEBUG off. For production I'll probably use some pg connection pooling (I use postgres). So only _rollback_on_exception remains. I plan to stick with Django autocommit behavior most of the time - will it work in this case? I only plan to use transactions if it is necessary to provide logical data consistency. — pajton, Jan 23 '12 at 19:29

Database connection management when using only Django ORM

1 Answers1