On 28 Kwi, 22:04, Jared Smith <jaredtsm...@gmail.com> wrote: > Using Django DB API I have two threads one that increments a counter getting > stored to the database and then another thread that is reading this counter. > > T1(Thread 1) increments > T2(Thread 2) reads > > I have found that if I increment and store the counter value in T1 and then > if I fetch it in the same thread I get the correct answer for the counter. > The fetched number matches what I store. > > However I notice that if T2 reads after T1 stores the value there is some > lag where it gives the wrong answer even though T1 is able to successfully > read the value with the same exact method. I put a loop spinning reading > this value and within a second or two it seems to get the right answer. > > Is there some lag for different threads to get the same results due to some > per thread caching happening under the covers? Anyone know of a work around > to make sure this cache is flushed? I'm worried I could get this problem > more generally since there are multiple threads accessing the DB and I need > to make all of them get the most recently committed value. > > Thank you for any advice, >
I'm guessing that this is happening to you: http://stackoverflow.com/questions/2235318/how-do-i-deal-with-this-race-condition-in-django/2235624#2235624 Note that you can also lower the isolation level to READ COMMITED (in case of MySQL) to get similar result, but READ COMMITED is allegedly (I read it somewhere) less used and therefore less tested that default REPEATABLE READ. -- Tomasz Zielinski http://pyconsultant.eu -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@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.
