Due to strangeness in the way mysql NDB Cluster works, select queries using a primary key or unique field in the where clause create a read lock for the duration of the connection...
IE in a python shell: In [2]: from django.contrib.auth.models import User In [3]: user = User.objects.get(username='myuser') will lock the row in the database for the duration of the python shell (IE he can't log in via the web anymore, or perform any action that will cause an update statement to his user row) If I commit after the select, then the problem goes away. IE: In [1]: from django.db import connection In [2]: from django.contrib.auth.models import User In [3]: user = User.objects.get(username='myuser') In [4]: connection.commit() After the commit, the user can now perform whatever action he desires via the web So, the question is, is this an error in the django mysql backend that it is assuming mysql is auto commiting, when in reality it is not (because the NDB storage engine doesn't work like myisam)? I don't know the inner workings of the db backends/transaction management well enough to understand what is supposed to happen. I think its crazy that mysql ndb requires a commit after a select to release a lock... but... such is the infrastructure I'm stuck using. Essentially though, if you're using mysql ndb cluster you have to issue a commit after every select to clear the locks on the rows selected. Any information/insight would be greatly appreciated. -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
