I've been upgrading some Django apps from Django 1.5 to 1.6, and am using Python 2.7.5.
One of the apps is a stand-alone app that uses the Django ORM to access a couple of MySQL databases. When it starts up this app spawns some worker tasks via Python's multiprocessing module. These workers also need to access the databases. This app worked on Django 1.5, but when dropping in Django 1.6 (and changing from using commit_on_success/commit_manually to atomic/set_autocommit) I got the following exception: ProgrammingError: (2014, "Commands out of sync; you can't run this command now") After some investigation it seemed that this may have been because the database connection was being shared between all of the processes. As each process was dropping in and out of the 'atomic' blocks of code the auto-commit state of the connection was being changed (Django 1.6 uses database-level auto-commit whereas Django 1.5 used application-level auto-commit). It seemed that the processes concurrently changing the auto-commit mode in an uncoordinated way was causing the 'ProgrammingError' exception. I fixed this by using database aliases in Django's DATABASES setting, see this link: http://stackoverflow.com/questions/22518156/multiple-concurrent-database-transactions-with-django I made sure that each process only used its own database connection which it could change the auto-commit state of without affecting the other connections. This got rid of the exception I was seeing. My question relates to a second app which uses nginx/gunicorn to also access databases through the Django ORM. This set-up could have multiple simultaneous users, so database accesses could overlap simultaneously in a similar way (although the affect of this is more difficult to test at the moment). The question is, could these concurrent accesses interfere in the same way as in the stand-alone app? I'm assuming that things will be fine, but the nginx/gunicorn model would seem to share similarities with the stand-alone app that uses Python multi-processing; it sounds like the gunicorn processes could share the same database connection. So the questions are: 1. Will the nginx/guicorn app be ok in terms of concurrent database accesses for Django 1.6? (I suspect the answer to this is yes, since the Django/nginx/gunicorn combination is, I believe, quite common) 2. If the answer to 1 is yes, why have I had to use database aliases to solve the problem in the stand-alone app? Is there a better way to do it, perhaps a Django setting I could use somewhere? 3. Why was this not an issue for Django 1.5? I have read that Django 1.5 tended to make separate connections to the database, but I haven't gone as far as observing how and when it might do this in our apps. Thanks to anyone that comments on this thread. -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/349125a7-17ab-4e01-8856-4204829b6083%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
