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
"Xerox" <an**@anon.co m> wrote in message
news:e6******** ******@TK2MSFTN GP12.phx.gbl...
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.
"Nick Malik" <ni*******@hotm ail.nospam.com> wrote in message
news:1m_td.4689 43$wV.356468@at tbi_s54... there are some commercial components that may provide better capability
for multithreaded sending.
--- Nick
"Xerox" <an**@anon.co m> wrote in message
news:en******** ******@TK2MSFTN GP15.phx.gbl... 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?
