On Tuesday, June 11, 2013 12:51:46 PM UTC-4, Vinny P wrote: > For now, let's ignore the transaction and exception details. Suppose you > make a simple datastore put, then immediately query the datastore for that > entity. There's a good chance that the entity that you just put in won't > exist, because it takes time for the datastore to commit and apply the > entity (fully write the entity, including all needed indexes, etc). The > time to fully write an entity differs depending on how big the entity is, > how many indexes are written, etc, but I usually ballpark it at around > 100-200 ms. As a side note, this is why sharding exists: because on a high > traffic app, a single entity simply cannot be written to fast enough to > handle all the incoming writes and not lose data. > > Within a transaction context, the same principles apply: depending on how > soon your db.get executes after the transaction Exception, you may get > stale data. The key here is the Exception: it's there to warn you that the > apply phase has been delayed for some internal reason. The apply may have > already occurred, it may be delayed for an unknown amount of time, or it > may not be valid anymore. So just to repeat: an Exception from a > transaction may cause stale data. >
I don't think this is correct. According to this article[1], if the transaction has been committed but not applied, then any subsequent reads, writes, or new transactions to that entity group will cause any unapplied transactions to be applied. So you should not see stale data in this case. [1] https://developers.google.com/appengine/articles/life_of_write -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/google-appengine?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
