I think you can handle this with a datastore transaction. See http://code.google.com/appengine/articles/transaction_isolation.html for more details.
The increment_counter example at http://code.google.com/appengine/docs/python/datastore/transactions.htmlshould be adaptable to your example. -Chris On Wed, Jul 14, 2010 at 10:17 AM, Sam <couponsys...@gmail.com> wrote: > In working with the data store, I've been able to solve all of my > "issues" (coming from a RDBMS background, had to rethink a few > things!), save for one. In the application I'm working on, it's > necessary to "reserve" a record at a moment in time and then display > that record to the end user, ensuring that each user gets a single > record and no duplicates are issued. Working with the record prior, > and using SQL as an engine, I was able to use the following query: > > UPDATE CCode SET SessionID = '" + strSessionID + "', Assigned = 1 > WHERE Assigned = 0 AND PartnerID = " + str(intPartnerID) + " AND > ExpireDate >= '" + str(dtCompareDate) + "' Limit 1" > > This would update the record in one pass and effectively reserve the > record for the established session, with no time lost inbetween > issuing the update and recording the change while SQL handled any > conflict resolution should two people request a record at the same > time. > > However, dealing with datastore, I seem to be running into some > problems with timing and wanted to know if anyone had any creative > ways around it. > > I realize that I can run a standard GqlQuery to return the results I > need and then update based on the returned result and add the session > to the record without a problem. What concerns me is the timing > factor. During the time it takes for the query to execute and the > resulting put() statement, it would be possible for another user to > arrive and make the same basic query recalling the same record set. I > know I could check for updates against the datastore before writing > back (used to do this years ago...), but this could potentially cause > a deadlock condition when the load on the system became greater and > multiple simultaneous users needed access to the records for selection > and updating. > > Any thoughts on how to work around this? > > -- > You received this message because you are subscribed to the Google Groups > "Google App Engine" group. > To post to this group, send email to google-appeng...@googlegroups.com. > To unsubscribe from this group, send email to > google-appengine+unsubscr...@googlegroups.com<google-appengine%2bunsubscr...@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/google-appengine?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to google-appeng...@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
