On Mon, Jul 25, 2011 at 4:30 PM, Pol <[email protected]> wrote: > On Jul 25, 7:30 am, "Nick Johnson (Google)" <[email protected]> > wrote: > > > The first part specifically refers to ancestor queries. Ancestor queries > > always operate on the latest copy of the data, as they're restricted to > an > > entity group; regular queries don't have that guarantee. > > 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. > > > > My understanding of this article is therefore the following (assuming > > > an HR datastore and that we are inside a transaction): > > > > > 1) Using db.get() / db.put() on an entity always executes on its > > > latest version: no race conditions possible, period. > > > -> Observations in my app appears to confirm that behavior. > > > > Correct, with the usual caveat about transactionality (if you're not > doing > > this inside a transaction, you have a potential race condition). > > Yes, I was assuming HR datastore + transaction (see above). > > > > 2) Using db.GqlQuery() / db.put() on entities in the same entity group > > > might still be subject to race-conditions: for instance, a previously > > > *committed* transaction modified the entities that would be returned > > > by the query in the later transactions, but the datastore indexes are > > > not up-to-date yet (or something like that), so the query doesn't see > > > the updated entities - even if calling db.get() directly on them would > > > return the versions that match the query. > > > -> I've reviewed my code carefully and I think I'm seeing such race > > > conditions in my app. > > > > Correct - but again, any update outside a transaction always has possible > > race conditions. > > Same here: I was also assuming HR datastore + transaction + ancestor > queries (by definition since inside a transaction). > > So is my code wrong or am I observing some very rare but expected race > conditions? > > Thanks > > - 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 [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/google-appengine?hl=en. > > -- Nick Johnson, Developer Programs Engineer, App Engine -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
