Hello Enrique, You have said that it is possible to hit 2 different datacenters. I believe appengine has a single primary dc and other one is just a passive failover. Am I wrong on this ? Does appengine have multiple active dcs ?
Thanks. Mete On Feb 3, 5:47 am, Enrique Perez <[email protected]> wrote: > Ok, so I will take a shot at this one.... > > Alot of the non-SQL datastores emerging are implementing consistency > models known as "Eventually Consistent". SimpleDb at Amazon is one of > these. The idea is that when your thread of execution writes to the > datastore your write call returns back from the datastore write call > fairly quickly and if you tried to read back your newly written entity > you may or may not get it back. But, eventually you would, maybe some > number of seconds later. There are many systems we use this > consistency model today. Email, for example.... > > Per Ryan Barrett, in Google I/O 2008 - Under the hood of datastore, he > described App Engine datastore as "Strongly Consistent". Other well > known "Strongly Consistent" systems you might have used are relational > databases or file systems. When you write an entity to the App Engine > datastore, the call blocks and only returns after the entity is > written to the entity table, and all indexes rows are written or > updated. Within the same thread of execution, if you were to try to > read back your entity you would always get it back. > > Now, there is another factor at play here which I have observed with > apps running in production. If you running your primary browser doing > datastore writes, you can open a second browser on different machine > and bring up your dataviewer. After you perform a write on browser #1, > you can refresh your second browser which is pointing to the data > viewer. Quite often you will not see the results of write from > browser #1 until some seconds later. I assumed that this was related > to the fact that the second browser was hitting a different data > center, or datastore clustor, and the replication from datastore > clustor #1 to datastore clustor #2 had not yet occurred. In Google I/ > O - 2009 - Weekend Projects - Barrett describes App Engine Multi- > homing techniqes. App Engine datastore is using Master-Slave > replication system which is I believe explaining why my browser #2 > takes some seconds to see the change. > > However, even with this behavior related to Multi-homing Master-Slave > replication in place, the App Engine datastore is still described as > "Strongly Consistent". If one were to implement Multi-Homing Master- > Slave replication with relational database technology I believe one > would still see the type of behavior I have just described. > > Hopefully this make sense and I have explained this correctly. If I > have gotten something wrong I would love to get a better understanding > of this. I love to hear any more detailed information on how things > work under the hood from those that know ... > > Thanks > Enrique Perez > Austin, Texas > > On Feb 2, 8:09 pm, smile laugh <[email protected]> wrote:> hello everyone > > > someone said that cloud computing is not real-time platform. > > > that is to say, if you insert a record into cloud(such as bigtable), > > and then if you query the record immediately , maybe no rowset > > returned. > > because in a cloud platform, a record is store in lots of server , at > > that time when you query that inserted record , some server may not be > > synchronized , and your query is done in those server.... > > > is that true? > > > thanks in advance -- You received this message because you are subscribed to the Google Groups "Google App Engine for Java" 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-java?hl=en.
