Hi Ikai, thanks for responding... On Jan 26, 2:28 pm, "Ikai L (Google)" <[email protected]> wrote: > I think there's actually a misunderstanding here - we don't guarantee > uniqueness of a key name. A String key is encoded into a datastore Key. The > datastore is, at its lowest layer, a key-value store. Uniqueness is > guaranteed because if you save an entity using a Key that is already used in > the datastore, it will overwrite the value stored at the current Key.
This is exactly what I was seeing, and trying to use as a basis for a programmatic uniqueness constraint. > It's sometimes easy to conceptualize the datastore as a giant, distributed > Hashtable. > > That being said, yes, if you must make sure no value exists at the current > key location, there most definitely exists a race condition. The logic I _desire_ is to have some way to prevent a race condition at the application level, e.g., when a user is selecting a login username. Having two users with the same username would be bad; but also having one user's login information clobber the other's because of datastore operation timing is bad too. In the relational world, this is achieved via a UNIQUE constraint on a field/column. In the case of a DHT as you compare here, it's usually by either preventing writes to an existing entity (atomic check-and- set), or by returning the already-existing value (atomic replace). So if the datastore doesn't support any of these notions, what is the correct/preferred method to prevent an application-level race condition when writing a value that must have a unique piece of data? There seems to be no documentation about this concept anywhere. -- 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.
