Hi Richard, I think your best approach is to simply use a datastore transaction (which supports retries), and show the user an error in the (rare) case that an exception occurs. In an auction, ordering of bids is important, so it seems far more important to give the user an immediate, accurate indication of whether or not their bid was accepted.
-Nick Johnson On Wed, Mar 2, 2011 at 11:52 PM, Richard Arrano <rickarr...@gmail.com>wrote: > Hello Robert, > I don't necessary even need to do it by tasks - what I'm doing is > something along the lines of a live ebay type auction, where I need to > guarantee that when user X wins the bid for product Y, I will a) > record this bid, b) be able to access it for the next item so I can > know that product Y is no longer available and c) I would like to be > able for the users to see which items have been previously sold(i.e. > some sort of history). I can do this in the normal way with the > datastore, but my concern is when the datastore has issues due to > latency and put() fails. I can't have this, and it's a very low rate > of writing with a low amount of data that needs to be guaranteed. > That's why I thought the task and encoding it in the payload might > work, but if I can't access what I previously wrote to the payload > then it won't. > > What about modifying it so that rather than attempting to access the > payload data, I give the task a name along the format of 'auctionId- > itemId' and in the payload, the bidder and the price. That way the > item cannot be sold twice, because we can't have two tasks with the > same name, and it will eventually get written if datastore writing is > down because the task will eventually be executed. What do you think? > I'm also a bit confused on whether or not a task eventually executes - > is it only transactional tasks that must eventually be executed and > don't get tombstones? In that case this won't work because I can't > name them. > > Thanks, > Richard > > On Mar 2, 9:04 am, Robert Kluin <robert.kl...@gmail.com> wrote: > > Hi Richard, > > Data in the task queue is not "accessible in some fashion when the > > user inputs it." There is currently no way to query / retrieve tasks > > from a queue, its a one-way-street so to speak. > > > > It sounds like you're implementing an autosave type feature? If you > > use memcache, remember it is just a cache and a given key (or the > > whole thing) could be flushed at any time. If you use the taskqueue > > (or deferred), remember that the tasks may not be run in the order > > they were inserted (particularly true if a queue backs up at all). if > > possible, you'll want to keep some type of revision count so you don't > > overwrite new with old. > > > > If you provide more info someone can probably offer additional > pointers. > > > > Robert > > > > On Wed, Mar 2, 2011 at 07:28, Richard Arrano <rickarr...@gmail.com> > wrote: > > > Hello, > > > I was reading the thread regarding wanting to guarantee a put() > > > (http://groups.google.com/group/google-appengine/browse_thread/thread/ > > > 8280d73d09dc64ee/1cf8c5539155371a?lnk=raot&pli=1) and I've found > > > myself desiring to do the same. It seems to me that using the deferred > > > task queue with < 10k of data will allow us to guarantee the data to > > > be committed at some point in time, regardless of datastore latency/ > > > availability. The scenario that interests me is when I have some data > > > I'd like to make sure gets committed at some later time(when exactly > > > doesn't matter), but it must be recorded and accessible in some > > > fashion when the user inputs it. I was thinking about using the > > > deferred task queue, but the problem is that although it's < 10k of > > > data, it will grow as the user inputs more data(they won't be able to > > > input everything at once). Could this be solved by retrieving the task > > > from the deferred queue and editing its payload. Is this possible to > > > do? Is there another solution that will fit what I'm looking to do? > > > > > Thanks, > > > Richard > > > > > -- > > > 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-appengine@googlegroups.com > . > > > To unsubscribe from this group, send email to > google-appengine+unsubscr...@googlegroups.com. > > > For more options, visit this group athttp:// > 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-appengine@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. > > -- Nick Johnson, Developer Programs Engineer, App Engine -- 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-appengine@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.
