Tim, It really depends on what you're doing. One of the challenges of developing on a distributed store like the App Engine data store is adjusting the way you approach persistence for objects. For instance, suppose you store favorite colors per application user. The canonical way of solving this problem in a relational environment is to normalize the color data and create a lock around inserting each individual new color. In App Engine's environment, we would likely recommend that you take advantage of data store list properties as a much more performant alternative to data normalization: App Engine will handle all the indexing for you.
If you are working with objects in parent/child relationships and require transactional integrity, you should take a look at our documentation describing Entities and Entity Groups: http://code.google.com/appengine/docs/java/datastore/transactions.html. On Fri, Nov 6, 2009 at 12:12 PM, [email protected] < [email protected]> wrote: > > Guys, > In a normal relational database, I am used to using a combination > of singletons (single application server), synchronized objects in a > dedicated thread (single application server) or table locks (multiple > application servers) to manage the creation of summary data records > which could created by multiple simultaneous requests. > In GAE, none of the methods seem to be supported; what would be > the suggested method? > > I am using the JPA method of accessing the data store. > > Thanks, > > Tim > > > > -- Ikai Lan Developer Programs Engineer, Google App Engine --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
