Thanks for the advice it appears that the issue was related to the old transaction sticking around.
I put: @transaction.commit_on_success On top of the method and it looks like I'm no longer getting stale data; guess I'll have to go do this around all data retrieval methods. I was assuming I needed this on the methods that changed data but didn't realize it would make a difference on methods that do reads in other threads. Thanks, Jared 2010/4/28 Tomasz Zieliński <tomasz.zielin...@pyconsultant.eu> > > > 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<django-users%2bunsubscr...@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/django-users?hl=en. > > -- 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.
