Weird issue with transaction.atomic in django 1.6

[tapan pandita]

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?

[Anssi Kääriäinen]

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

[tapan pandita]

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.

[tapan pandita]

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.