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.
