The request headers will not help. You'll run into problems whenever you are doing an api call that return with an unknown state and the method you are calling is not idempotent (like sending mail, creating a contact etc.) So in case of email you can add your app as bcc and use a mail-in handler to check whether the mail has been sent successfully or not. This is an ugly workaround but there is nothing else that comes to my mind.
On 12 Jul., 22:54, Marcus Brody <mhrab...@gmail.com> wrote: > dflorey and Pieter, > > thank you for the links, > I will look into it asap. > > On Jul 12, 10:35 pm, Pieter Coucke <pieter.cou...@onthoo.com> wrote: > > > > > You can check request headers to see if this is a first invocation of a task > > (http://code.google.com/appengine/docs/java/taskqueue/overview.html#Ta...), > > so you can detect a second invocation of a task. > > > Maybe if you combine this with specific catch blocks for mail exceptions? > > > On Mon, Jul 12, 2010 at 10:07 PM, Marcus Brody <mhrab...@gmail.com> wrote: > > > Pieter, > > > > although this looks easy its not that easy, I am aware that I can > > > queue a mail sending task, > > > problem is that task has to be idempotent to achiev desired behaviour, > > > > a queue task can be executed for example twice, since those are > > > specifications > > > and this would result in sending mail twice, > > > a naive aproach would be to update some db lock to prevent sending > > > mail more than 1 time, > > > but it is not easy, this is much more complicated, > > > in other words operation is either atomic or it isnt, and without very > > > precise mechanism you > > > cannot prove that task will be runned only one. > > > > My own tests proved that due to email quota being reached (task fail > > > and has be resheduled) some of the mails > > > has been send twice. > > > > If Mail API would allowed to send mail only in case of some db > > > transaction success it would be very easy to garant > > > that mail will be send exactly 1 time. (although if it fails for some > > > other reasons like recipient not found or so thats whole another > > > story :) > > > > Basically this can be solved by > > > 1) adding new API for sending mail (dont know if it so easy or whole > > > problem isnt much much bigger than i think - distributed > > > transactions ?) > > > 2) implementing locking mechanism > > > > On Jul 12, 9:13 pm, Pieter Coucke <pieter.cou...@onthoo.com> wrote: > > > > Create a task for sending e-mail instead of calling the mailservice > > > > directly. > > > > > use this in your task (a task can be part of a transaction) > > > > > try{ > > > > ... > > > > > } catch (Throwable thr) { > > > > log.error(...); > > > > } > > > > > and all exceptions will be catched. I think a task will be re-executed > > > only > > > > if it fails (throws an exception). > > > > > On Sat, Jul 10, 2010 at 6:43 PM, Marcus Brody <mhrab...@gmail.com> > > > wrote: > > > > > Hello, > > > > > > I would like to ask, if there is some way how to send mail only in > > > > > case that some db transaction will be successful. > > > > > I am not very experienced with gae, but I did study it now for about 2 > > > > > weeks. > > > > > > Desired output: > > > > > > 1) prepare email > > > > > 2) db transaction.begin() > > > > > 3) do some db operation > > > > > 4) bind sending mail with current transaction (similar to > > > > > how can you can attach Task to queue) > > > > > 5) db transaction.commit() > > > > > > I am aware that I can queue mail sending task to task queue, but i > > > > > cannot find the way how to do that mail sending task Idempotent > > > > > without (i think) complicated locking mechanism . > > > > > Most simple solution would be to put mail sending task to task queue, > > > > > but this means mail could be send twice in some rare situation. (this > > > > > is maybe not that bad but if there is some way how to avoid it, I > > > > > would like to know) > > > > > > Thank you, > > > > > > Marcus > > > > > > -- > > > > > 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 > > > > > google-appengine-j...@googlegroups.com. > > > > > To unsubscribe from this group, send email to > > > > > google-appengine-java+unsubscr...@googlegroups.com<google-appengine-java%2B > > > > > unsubscr...@googlegroups.com> > > > <google-appengine-java%2bunsubscr...@googlegroups.com<google-appengine-java > > > %252bunsubscr...@googlegroups.com> > > > > > > . > > > > > For more options, visit this group at > > > > >http://groups.google.com/group/google-appengine-java?hl=en. > > > > > -- > > > > Pieter Coucke > > > > Onthoo BVBAhttp://www.onthoo.comhttp://www.koopjeszoeker.be > > > > -- > > > 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 > > > google-appengine-j...@googlegroups.com. > > > To unsubscribe from this group, send email to > > > google-appengine-java+unsubscr...@googlegroups.com<google-appengine-java%2B > > > unsubscr...@googlegroups.com> > > > . > > > For more options, visit this group at > > >http://groups.google.com/group/google-appengine-java?hl=en. > > > -- > > Pieter Coucke > > Onthoo BVBAhttp://www.onthoo.comhttp://www.koopjeszoeker.be -- 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 google-appengine-j...@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
