Re: Weird issue with transaction.atomic in django 1.6

Also there is no other view that could possibly be writing to the same row. There are 5 rows in 5 different tables that get affected showing symptoms similar to a rollback without any exception being raised. It's really hard to imagine all of them had concurrent writes going on at the same time even if it was somehow possible.

On Thursday, February 27, 2014 12:38:50 PM UTC+5:30, tapan pandita wrote:

I did initially think that it might have been a concurrent write messing with the DB but I was able to see this issue locally once where this view was the only one being called. The objects being saved were also using update_fields and had the correct value on them while calling save. Is there a db setting or django setting (maybe a default that I haven't changed) that could be interfering with transactions and cause behaviour like this?

I'll turn on logs for the database, but I can't really narrow down on a repro pattern for this which makes it all the more difficult to catch it. I've faced it only once locally. Logging all on our production database is not an option since there are a lot of queries.

On Thursday, February 27, 2014 12:13:28 PM UTC+5:30, Anssi Kääriäinen wrote:

On Wednesday, February 26, 2014 11:58:54 PM UTC+2, tapan pandita wrote:

I am using transaction.atomic as a context manager for transactions in django 1.6. There is a block of code which I want to be in a transaction which has a couple of network calls and some database writes. I am seeing very weird behaviour. Every once in while (maybe 1 in 20 times) I have noticed a partial rollback happening without any exception having been raised and the view executing without any errors. My application is hosted on heroku and we use heroku postgres v9.2.8.

I have described the problem in greater detail here http://stackoverflow.com/questions/22053846/weird-behaviour-for-transactions-in-django-1-6-1

Any ideas?

Partial rollback shouldn't happen. Are you absolutely sure there is a rollback? For example concurrent modification could lead to saving old values back to the DB.

One way to check what is happening is to switch on all logging for the problematic part of code (use "SET log_statement to 'all';") , then checking database logs. You don't want to turn log_statement to 'all' if your app generates a lot of queries.

 - Anssi

--
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 http://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/cd2c32ad-ab90-480d-8ab6-2dec8cf7fcbe%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.