Hi, I'm having some trouble with this article in the scope of the HR datastore: http://code.google.com/appengine/articles/transaction_isolation.html
It says: > In a High Replication datastore the transaction is typically completely > applied within a few hundred milliseconds after the commit() returns. > However, even if it is not completely applied, subsequent reads, writes, and > ancestor queries will always reflect the results of the commit() because > these operations apply any outstanding modifications before executing. But then just afterwards, it also says: > However, if a concurrent request executes a query whose predicate (the 'where > clause' for you SQL/GQL fans out there) is not satisfied by the pre-update > entity—but is satisfied by the post-update entity —the entity will only be > part of the result set if the query executes after the apply operation has > reached Milestone B. "ancestor queries will always reflect the results of the commit() because these operations apply any outstanding modifications before executing" != "the entity will only be part of the result set if the query executes after the apply operation has reached Milestone B" 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. 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. Can Google folks confirm #2? And if yes, how do you effectively work around this limitation? Is there such a thing as a flush() command? Some extra param to say commit and wait for real completion at the end of the transaction? I'm OK with extra latency per-entity group, but I really need to avoid race conditions in this specific part of my app. 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 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.
