I would pass of the email sending to a task queue, and wrap the
success of the send in a transaction
and only update to yes if the email send call returns ok.

At least you off load your work from the primary transaction.

Remember email isn't really a reliable service, and even if you do
mark it as sent it may never reach the recipient.

Pushing the send email workload and recording if you sent it into a
task should not really cost you to much
in end user response times/latency.

 As someone else put it email is not transactional in any sense.  Its
very much a
"throw it over the fence and hope it gets there in the next few days"

T

On Mar 18, 11:47 am, prgmratlarge <[email protected]> wrote:
> I guess all of you are technically correct. However, the solutions
> given were either: a) introduce a tremendous amount of latency/CPU
> usage in terms of putting/checking/deleting things from the datastore
> b) live with it. I think it's kind of weird for them to use this
> specific case as an example, when it clearly isn't the best example.
>
> I guess I'll just have to hope that everything goes okay, and write
> lots of try/except clauses in my code to make sure the "little things"
> don't mess stuff up.
>
> Thanks anyways,
>
> On Mar 17, 9:46 pm, Eli Jones <[email protected]> wrote:
>
>
>
> > Like Tim says... if you're really worried about sending out a duplicate
> > e-mail from time to time... then you'll need to design your mailer task to
> > do something like this:
>
> > 1.  Mailer task starts.. gets a batch of work from some datastore Model that
> > serves as your queue.
> > 2.  Process a row of work, and after you successfully send out an e-mail for
> > that row delete the row from your queue.
>
> > Then just do step 2 over and over until you finish all of your work.. or if
> > some error forces the task to retry.. then it should get a new batch of work
> > from your queue.. which should now contain only entities that have not been
> > processed.
>
> > The only case where you'd get a duplicate email sent for a row of work would
> > be if the email successfully was sent out.. but an error occurred when
> > trying to remove the row from your queue.
>
> > And, even in that case, you could add try: except: blocks to do everything
> > possible to avoid that (just retry the db.delete() from your queue, etc).
> > (Then, only the 30 second limit would be a concern.. but you can handle that
> > as well).
>
> > Then again, you really have to be adamant about avoiding the potential
> > duplicate e-mail issue to do this sort of thing.
>
> > On Wed, Mar 17, 2010 at 8:53 PM, Tim Hoffman <[email protected]> wrote:
> > > Well could yo record if you sent any particular email, and
> > > not resend it ?
>
> > > On Mar 18, 6:05 am, prgmratlarge <[email protected]> wrote:
> > > > "When implementing the code for Tasks (as worker URLs within your
> > > > app), it is important that you consider whether the task is
> > > > idempotent. App Engine's Task Queue API is designed to only invoke a
> > > > given task once, however it is possible in exceptional circumstances
> > > > that a Task may execute multiple times (e.g. in the unlikely case of
> > > > major system failure). Thus, your code must ensure that there are no
> > > > harmful side-effects of repeated execution." -http://code.google.com/
> > > > appengine/docs/python/taskqueue/overview.html
>
> > > > According to this part of the documentation, it would seem that
> > > > setting up an email-sending task-queue is impossible. After all,
> > > > sending someone the same email thousands of times would be disastrous.
> > > > Yet the documentation also gives email sending as an example use of
> > > > the Task Queue.
>
> > > > This seems to be contradictory. How can I create a Task Queue for
> > > > sending email without running into problems of idempotence?
>
> > > > Thanks for your help.
>
> > > --
> > > 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]<google-appengine%2Bunsubscrib
> > >  [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.

Reply via email to