Hi Richard, Thought I'd comment since I started this thread. Think Wim and Robert have helped already more than I could. So just some thoughts from me.
First: I hope any GAE engineers reading this thread might have a thought sparked about task queue featured needed for highly important, lower-volume tasks such as yours. My problem is that I've got to record a one-time purchase payment. Yours is more complicated. My issue was the all the steps needed to setup and maintain a payment record for a Paypal for an Express Checkout purchase (digital good). Rather than risk any loss of the update in the handler functions (which already has to deal with sending urlfetch calls to Paypal), I send the responses from Paypal to a high-priority task queue for the put()s. This high-priority queue is pretty strict about very lightweight imports, and record updates (i.e. no complex indexes on records being updated). Hopefully this keeps issues related to slower task handlers low. Look to Wim's link in this thread for many helpful points about "handler weight control". Since I can't move forward with Express Checkout until the payment record has been put() by the high-priority queue, the client starts to send a request to the on-line handler once every second (with a nice dialog explaining the delay for the customer). If the new payment record has not been put() after 10 client calls, then I go into damage control on the client side. Hopefully this happens very infrequently. The alternative for me is to have the on-line handler send the urlfetch call to Paypal, put() the new payment record upon PP's response, and then respond back to the client with "result=OK". If all this happens, then the client knows to proceed because the initial payment put() has been done. I just felt that there was a greater risk of failure having all this functionality in the one on-line handler function. Perhaps with HR, this is unfounded, but I'm not sure there's enough anecdotal evidence to support this yet. This of course encumbers the user with an additional dialog and a bit more wait time, but I don't think it is too much as many purchase processes on-line take a bit of time. Plus, if we can't get this all done within the allotted time, the damage control is very favorable to the customer and penalizes me which is as it should be (Google of course getting its cut either way -- actually a bit more should GAE be running slowly thereby expending more CPU cycles than normal :-). -- 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.
