If you collect the keys of newly created 'small entities' and send them in batch to the back end for reaping, you could use a batch get() which would force all the entities to roll forward, and eliminates the eventual consistency issue.
Unfortunately, I believe that no matter the solution architecture, you ALWAYS have the possibility of a latency spike with any GAE service, which why the 10s window is so challenging. On Wednesday, August 1, 2012 2:01:43 PM UTC-4, Richard wrote: > > Yep... got that. However, a query() will still return stale data between > the put() and the (internal) commit(). Which is where I believe I am > sitting... > > On Wednesday, August 1, 2012 12:39:41 PM UTC-4, Jeff Schnitzer wrote: >> >> I presume the essential line is this: >> >> "In the (now standard) High Replication Datastore, the transaction >> typically is 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." >> >> ...which is interesting and not something I ever thought of. I don't >> think this intermediate state was discussed in Alfred's "Under The >> Covers" I/O talk last year. Can someone describe it in more detail? >> >> Jeff >> >> -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To view this discussion on the web visit https://groups.google.com/d/msg/google-appengine/-/dvqJHBUINVQJ. 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.
