Comments on: Stop premature email sending with NServiceBus

By: Zedd

Zedd — Thu, 08 Dec 2011 04:24:00 +0000

This works as long as the service bus participates in the transaction. I’m not sure this is always the case.

By: Anonymous

Anonymous — Fri, 25 Nov 2011 18:31:00 +0000

I want the sending of an email to succeed if the saving succeeds. Having the message inside the transaction is the only way to really guarantee that this happens. Otherwise, having the message outside the scope is just something else I’ll have to manage in terms of failures and retries. With messaging and NServiceBus, I get that for free.

Transaction scopes are not something I should have to explicitly manage. They should be managed for me in an infrastructure layer.

As far as keeping track of statistics, that’s really orthogonal to the act of sending them. If I don’t want to mix the concerns of sending emails versus keeping statistics on emails sent, I’d just publish an event when the email is actually sent so that another tailor-made component can do whatever it needs to do to record whatever information is needed.

By: Anonymous

Anonymous — Fri, 25 Nov 2011 18:27:00 +0000

Do you have an example not using SSSB? In terms of simplicity, I’m not sure how SSSB is easier than message queuing. Not to mention, MSMQ can be installed on absolutely any Windows OS, but IT admins are much more restrictive about installing DB components on just any machine.

By: Distributed Weekly 130 — Scott Banwart's Blog

Distributed Weekly 130 — Scott Banwart's Blog — Fri, 25 Nov 2011 14:16:50 +0000

[...] Stop premature email sending with NServiceBus [...]

By: ToOsIK

ToOsIK — Fri, 25 Nov 2011 13:44:00 +0000

Hmm, I like your concept, and I understand your approach, but that sounds like a very round-about way to get solution for a very simple problem.

Why cant you just send the email when you have finished committing the transaction? (the one that wraps your method above)

I mean it sounds like the email is relevant to the full transaction, not this method, why is this method sending the email? it just looks like the code is not structured properly!

Very good article tho, clear and informative, just not for this specific scenario you indicated.

Also, I would use a database table to maintain that, only because I would be able to slice and dice through the data, and infer interesting patterns based on aggregations, like:

>when most emails are sent
>which email profiles are most used
>what time of the day we have the most load, etc.

By: Finoutlook

Finoutlook — Fri, 25 Nov 2011 11:22:00 +0000

For example you could use Service Broker in SQLServer http://msdn.microsoft.com/en-us/library/ms345108(v=sql.90).aspx

By: Anonymous

Anonymous — Thu, 24 Nov 2011 19:16:00 +0000

How would you set it up? Usually I see folks doing cron jobs. The messaging system works via events, so it’s not like the process is constantly waking up.

I only say this cause a system I worked on was moved from a bunch of cron jobs to messaging, and we saw CPU drop quite a bit. But if there are other ways besides cron jobs, I’d love to hear about them.

By: Finoutlook

Finoutlook — Thu, 24 Nov 2011 17:49:00 +0000

No more than the messaging system is waking up constantly to ping a message queue. You don’t have to set up your DB to work that way.

By: Sean Kearon

Sean Kearon — Thu, 24 Nov 2011 11:47:00 +0000

Quite! AFAIK you’d have to code the handling between the commit and send yourself.

“NServiceBus is overkill for the case.” – Assuming you have MSMQ available an NSB email endpoint is a relatively simple option. NSB’s deployment story so sweet, it’s a breeze!

By: Anonymous

Anonymous — Wed, 23 Nov 2011 20:22:00 +0000

How would it be decoupled? Having another process check periodically on the success of things and send out emails?

You can build a queue using a database and scheduled cron jobs, but why? An ESB is easier and you don’t have some process waking up constantly to ping a database.