Re: TransactionManagementError from inside atomic block

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 <charette.s@gmail.com> 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 django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
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.
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 django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
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.