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.
