If you want to prevent re-inserting the same task over and over you might want to look into naming your tasks, if there is a natural "name."
Robert On Wed, Sep 29, 2010 at 23:22, Broc Seib <[email protected]> wrote: > You should write you code to expect the data store to be read-only > on occasion. You ought to at least expect the scheduled maintenance > periods. > Two tips to stay informed of these: > 1) You can add the scheduled downtimes to your calendar: > iCal http://www.google.com/url?sa=D&q=http://www.google.com/calendar/ical/4chlpo92ci2f54c2u21shbjk9o%2540group.calendar.google.com/public/basic.ics&usg=AFQjCNEFdmBiFhvLBYbXEKRBqbiNtyA0iw > 2) And subscribe to downtime > notifications: http://groups.google.com/group/google-appengine-downtime-notify > > > Now, here is how the docs say you are supposed to do to handle these > situations. Essentially, you must catch CapabilityDisabledException and > decide if the data write needs to be tried again later or not. > > http://code.google.com/appengine/docs/java/howto/maintenance.html > For applications using JDO to work interact the datastore, use the > following code: > PersistenceManager pm = PersistenceManagerFactory.getPersistenceManager(); > try { > pm.makePersistent(object); > } catch (com.google.apphosting.api.ApiProxy.CapabilityDisabledException e) > { > // Datastore is read-only, degrade gracefully > } finally { > pm.close(); > } > > I have adopted the pattern of catching CapabilityDisabledException (which is > an unchecked exception) and throwing my own DowntimeException (which is a > checked exception). I let the caller decide whether to retry or not. > My pattern for "retrying later" is to create a URL that represents the > method call that just failed with a DowntimeException. That means enough > info encoded in the URL to know how to make the exact same call to that > method again with the same arguments. Then I create a task with that url and > add it to a queue, which will try repeatedly until the call succeeds. (Check > out QueueFactory and TaskOptions.Builder.url() ). Also, be sure you don't > keep adding the task to the queue when it fails. This is why you should > throw a checked exception and let the caller decide to add a retry task to > the queue rather than have the actual call add it to the queue (again and > again). > There are some cases where you would not want to set up a retry. You have to > examine every single place in your code where you call pm.makePersistent() > and decide what the impact is for you. Yes this is a pain, but the time > spent is a minor price for the scalability you get. Besides, your IDE can > quickly find all these spots in your code. It will take time to decide the > impact of each of them. > I can post my RetryTask framework if it might be of use to anyone... > -broc > > -- > You received this message because you are subscribed to the Google Groups > "Google App Engine" 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?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 [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.
