Hey Simon, Thank you for your response, we were able to resolve the problem soon after I posted the query.
And yes, you are correct, it was an issue with having multiple DB connections and the `auto-commit` being turned off for one, but then another connection being used for querying. We earlier had a master-slave configuration for our DB and were using a DB router to route all reads to the slave. That is still in use and that is why the `deafualt` connection was used as we entered the `atomic` block, but `slave` when we made the read. Thank you again. On Thu, Mar 30, 2017 at 4:39 AM Simon Charette <[email protected]> wrote: > Hi Ketan, > > I'm afraid this will be really hard to solve without the code that is > raising this exception. > > Some details that could help debug the issue: > > 1. Are your workers multi-threaded? > 2. Are you sure you are not calling functions performing manual > transaction management? > 3. Is your atomic() block using the same database involved in the > select_for_update() call? > > e.g. Are you using transaction.atomic() (which will use the default > database) > but have database routers that could route reads/writes to another db? > > Cheers, > Simon > > Le samedi 25 mars 2017 15:08:19 UTC-4, Ketan Bhatt a écrit : > > I have a method that updates a row in the table. > To avoid race condition, I locked the row using `select_for_update` inside > an `atomic` block and doing the update. > This method is called from a celery task. > > This works well on my local machine. But when this gets called on my > production server (two tasks being picked up by two workers at the same > time and therefore trying to access the same row at once), I get: > `TransactionManagementError('select_for_update cannot be used outside of > a transaction.',)` > > I checked that to use `select_for_update`, autocommit should be False. > Inside the atomic block `get_autocommit` returns False. > > Now on production this must be returning `TRUE`. > > > What could be the reason? > > -- > 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 [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/django-users. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-users/91f6b088-e255-4ff9-a9c5-f033ffdf4211%40googlegroups.com > <https://groups.google.com/d/msgid/django-users/91f6b088-e255-4ff9-a9c5-f033ffdf4211%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CACyRkBVpKO1Khuf4Z%3D_PggA3TPcFa92anCgC_p_tzw92kwbQVw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
