Does High Replication DB "eventually consistent" mean that detached JDO objects may not always contain updated object graph?

I have been using the Master/Slave database for previous App Engine projects but my new app is defined as High Replication Datastore (I don't believe this setting can be changed after it is defined).

What I have been doing up until now is calling detachedCopy on an object after an update so that a subsequent update is sure to be working with the newly updated object graph.

However, the High Replication Datastore has a characteristic that I don't fully understand but am worried about - namely "eventually consistent". What I have heard from some Python people on the Google App Engine group is that they will perform an update on a 'mod开发者_如何学Goel' object but because the High Replication Datastore doesn't return the updated object graph until it feels like it, any subsequent updates to this object may now be out of sync with the underlying datastore.

If this is correct, it kind of screws the way I have been using detachedCopy in Datanucleus JDO - under the Master/Slave database I never encountered a situation where the detached object was not consistent with the datstore. Is this something I need to worry about now and is there some way to avoid catastrophe with the High Replication Datastore? Or should I simply run all of my apps against the Master/Slave configuration to avoid this problem if there is no JDO workaround for it?

---

"JDO" returns the objects that it has in detached state from detachCopy. If the datastore doesn't update itself then that is the datastore only and "JDO" doesn't care about it (except I suppose until you try to update the datastore with updated forms of those objects).