On Jul 26, 6:15 am, "Nick Johnson (Google)" <nick.john...@google.com> wrote:
> > I understand that, but my problem is with the indexes: even in the > > scope of HR + transactions, the doc is confusing regarding wether or > > not there can be a race-condition on indexes update. > > > For instance: > > - transaction A modifies entity X and commits > > - then transaction B happens almost concurrently: > > - at this point, using db.get() X will return the latest X no matter > > what > > - however, using db.GqlQuery() with a predicate that matches X *may > > not* return X because the indexes may not be done updating yet (the A - > > > B thing in the doc) > > > So is this race-condition possible or not? No matter what, you might > > wanna rewrite a couple sentences in this article :) > > Again, this depends on if you're using an ancestor query. Queries that > include ancestor filters are strongly consistent, queries that don't aren't. Since I'm inside a transactions, I am indeed using ancestor queries. So I'm going to interpret your answer as "with HR and ancestor queries, there can be no race-conditions at all due to index updates no matter what the doc says about concurrent transactions and small windows." :) For the record, I did end up finding a bug in my code that explained the fact sometimes concurrent transactions with ancestor queries were apparently returning stalled results. - Pol -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to google-appengine@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
