Ok, so, gets can use eventual consistency, but that's not the default. Is that correct?
If so, I agree with you that that sentence should be changed. "Remember, if you do a get(), put(), or a transaction, you will always see the most recently written data." http://code.google.com/appengine/docs/java/datastore/hr/overview.html On Jul 10, 5:41 pm, Stephen Johnson <[email protected]> wrote: > Hi Kyle, > You should read the link I provided with Ikai's discussion. Gets by key with > EVENTUAL consistency on HR can go to a replica datastore that may not have > the latest info. Also, see the discussion we just had where this was > discussed. Subject was ReadPolicy.Consistency.EVENTUAL under HR The > documentation is misleading about gets under HR which I point out in that > discussion. > Stephen > > > > > > > > On Sun, Jul 10, 2011 at 2:31 PM, Kyle Mulka <[email protected]> wrote: > > The example you describe will be strongly consistant in the high > > replication datastore. Take a look at the consistency section of the > > table on this page comparing master/slave with high replication: > >http://code.google.com/appengine/docs/python/datastore/hr/ > > > You'll see there that gets, puts, and deletes are strongly consistant > > even with high replication. > > > From everything I've read about and experienced with regards to the > > high replication datastore, the only case where eventual consistency > > comes into play is with a query across entity groups. Each entity > > exists within its own entity group unless it has a parent, in which > > case it is grouped together in the same entity group as its parent. If > > you retrieve an entity from the datastore by its key, that will be > > strongly consistant because it only queries one entity group. -- > > > -- > > Kyle Mulka > > Co-Founder, DealSavant > >http://www.dealsavant.com > > > On Jul 10, 12:33 pm, bejayoharen <[email protected]> wrote: > > > I am designing an app that may not work well with the eventual > > > consistency model provided by the HR database, and thought someone > > > could provide some advice. Here is a typical situation: > > > > 1. Client A requests storage of data identified by KEY on GAE. > > > 2. the GAE app stores the data; and acknowledges the storage to Client > > > A. > > > 3. Client A tells Client B (via another communication protocol) to > > > fetch data identified by KEY. > > > 4. Client B asks GAE for the data identified by KEY. > > > > Unfortunately, with eventual consistency, step 4 may fail. Caching > > > won't help because 1. caching is not 100% reliable and 2. client A and > > > client B may be talking to different nodes with different caches. > > > Worse than this is a situation where instead of storing the data, > > > client A is updating and client B gets stale data. > > > > Is there some solution to this, or do I need to use the MS database? > > > If that's the case, I noticed that in some places, the MS database is > > > marked as "legacy", which has me worried. > > > > thanks > > > > bjorn > > > -- > > 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. -- 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.
