SmtpMail - not multithread friendly?

  • Thread starter Thread starter Xerox
  • Start date Start date
X

Xerox

The SmtpMail class has a static property to set the server and a static
method to send an email. But if its static, how can it work in a
multithreaded environment? Surely one would want to create an instance of
the server and invoke the send() method?
 
there are some commercial components that may provide better capability for
multithreaded sending.

--- Nick
 
My code will be running inside a server (BizTalk server). I don't have
control over the number of threads, BizTalk manages this. Therefore, would
you say that using SmtpMail is unsafe in an environment like this? Should I
wrap all use of SmtpMail within a static synchronized method?

I can envisage a scenario where one thread changes the smtp server property,
is just about to call send message, when another thread that it knows
nothing about updates the smtp server property to something else.
 
Actually, what I would recommend is that you purchase, for less than $300, a
license for a commercially available SMTP component that is multi-thread
ready, rather than adding a bottleneck that will undoubtably cost you
considerable performance in a biztalk environment.

Performance hits in biztalk are very difficult to diagnose, and may of my
past clients have gone so far as adding expensive hardware as a "test" to
see if Biztalk performance would improve.

Given the potential for future expense due to a design flaw in a small
corner of .net, why not spend a small amount of money, right now, for a
component that doesn't have the flaw?

Otherwise, for the hope to save $300, you could slow down a system that
costs thousands, and incur the liklihood that additional thousands will be
spent trying to shore it up.

--- Nick
 
Very sound advice, thanks Nick. As you state, it is a bit of a design flaw
in the framework - unusual though that they should have done it that way.

Thanks again.
 
Back
Top