There is no reason to care about the lost Id, IMO. Presumably collisions are relatively infrequent in any case.
If you use the canonical URL as the key for the entity, it guarantees only one instance of the URL in the datastore. If you use the allocator to generate Ids (as Jeff suggested), they are guaranteed to be unique for the specified entity. The allocation itself doesn't need to be inside the transaction, though; you could grab them in batch and create an instance-local cache to retrieve them. Of course, pay due care to ensure that a given Id is used only once (the simplest way would be to synchronize the retrieval method and make it single threaded). On Wednesday, August 8, 2012 1:29:34 AM UTC-4, Neo wrote: > > Hi Jeff and Michael, > > Yes, I am looking for a way to ensure that multiple servers don't create > the same URLInfo object at the same time. > > As Michael said: If you use a transaction to retrieve the entity by key > (the URL) and then create one if it doesn't exist, only one entity should > be successfully created in the event of a collision. Therefore, *even if > you create two different versions with different unique ids,* only one > should survive. > > My question is do we really need to care about the lost Id (as only one > entity is going to survive) in the case of collision? And can we have code > snippet for allocating and assigning id to the URLInfo in the transaction > that guarantees that there shall be only one instance of a URL in the > datastore and the Ids of all the URLs are unique and non empty? > > Thanks for your patience. > -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To view this discussion on the web visit https://groups.google.com/d/msg/google-appengine/-/it27kwGgxtkJ. 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.
